I do have an existing JAVA based SOAP API and I a, trying to build a REST API instead.
JSON is not preferred for big payload.
(How Big is Big for JSON)
My Report generation API returns a XML payload ranging from 350kb to 1MB.
Not sure what the suggestion is.
Question-
Should I go with REST/JSON or REST and something else?
Also what is the best design opinion for me to consider while moving from SOAP to RESTful
Any tools or framework, you may recommend?
Sorry if this is very open. I can provide more detail, if you suggest?
The technology I intend to use is all Java based
Well SOAP/XML is bigger in any case than a REST/JSON payload. Besides JSON works well even in this size range.
I would consider thinking your API from start while considering RESTful best practices. JSON is simpler than SOAP and with some practice RESTful design will seem natural.
Finally in Java you may use JAX-RS
Protocol Buffers are a way of encoding structured data in an efficient yet extensible format. Google uses Protocol Buffers for almost all of its internal RPC protocols and file formats.
https://code.google.com/p/protobuf/
Related
Could anybody explain advantage of using json-rpc over json-api and vice-versa? First and second format are JSON-based, but where I should use one, and where is another?
Note: I may come across a little biased. I am the author of the Json-RPC.net server library.
Json-RPC is a remote procedure call specification. There are multiple libraries you can use to communicate using that protocol. It is not REST based, and is transport agnostic. You can run it over HTTP as is very common, you can also use it over a socket, or any other transport you find appropriate. So it is quite flexible in that regard. You can also do server to client along with client to server requests with it by hosting the RPC server on either the client or the server.
Json-API is a specification for building REST APIs. There are multiple libraries you can use to get started with it. In contrast to Json-Rpc it requires you to host it on an HTTP server. You cannot invoke functions on the client with it. You cannot run it over a non-http transport protocol. Being REST based, it excels at providing information about Resources. If you want an API that is based around the idea of Create, Read, Update, Delete on some collections of resources, then this may be a good choice.
Json-API is going to be better if your API is resource-based, and you want your API to be browsable by a human without setting up documentation for it. Though that human would likely need to be in the software engineering field to make any sense of it.
Json-RPC is going to be better if your API is function based, or you want the flexibility it provides. Json-RPC can still be used to manipulate Resources by creating Create, Read, Update, and Delete functions for your resources, but you don't get the browsability with it not being REST based. It can still be explored (not browsed) by a human by generating documentation based off of the functions you expose.
A popular example of something that uses Json-Rpc is BitCoin.
There are a lot of popular REST-based API's and Json-API is a spec with a bunch of tools to help you do REST right.
--
Note: Neither of those (Json-RPC, or Json-API) are good when you consider for developer time, performance, or efficiently using network resources.
If you care about performance, efficiency, or developer time then take a look at Google's gRPC which is fantastic in those regards, and can still reduce developer time more than using a REST API as client and server code can be generated from a protocol definition file.
I´ve been checking the Rest API and I cannot find an API to delete a particular document, or all documents of one particular view. Just the delete of the bucket or view.
Anyone know if is that possible?
generally speaking the (official, supported) REST API will deal with the cluster and buckets, whereas key/value operations are handled through the memcached binary protocol, and the SDKs are here to give you a facade over all this (including k/v) in your language of choice, idiomatically.
tl:dr no at least not in a supported stable way, you should use one of the SDKs
I can't find it either. Of course you could easily roll your own front-end wrapping a Couchbase client. Here's an example in ruby this.
Can someone point me in the right direction or give me some instructions on how I would publish a site that offers JSON? I know this may sound a bit basic. I have some SQL data that I want to convert to JSON and then have other devices request the JSON using a URL I provide.
You have a lot of options as far as server-side technology, but in the end, you need to accept the parameters, select your data and return content that is application/json. Since you have a SQL Server back-end, you might look at Microsoft's Web API as the technology to expose your data.
My application uses GWT-RPC to communicate to the server. Is there anyway to transparentlly serialzie my data using JSON without changing the RPC layer?
IMHO this could be acheived by changing the serializers and using autobean codex in the UI.
Why do I need that?
I want to make cross domain RPC calls
I want to call the server side from a non GWT-app without providing an extra layer in server side.
UPDATE I just stumbled upon http://code.google.com/p/gerrit/source/browse/README?repo=gwtjsonrpc which is actively maintained (as it's part of Gerrit, the code-review tool used by the Android team)
Have a look at http://code.google.com/p/gwt-rpc-plus/ but it's no longer maintained...
If you really need it and don't want to move away from GWT-RPC, then replacing GWT's serializers should be possible: that's exactly what deRPC (com.google.gwt.rpc) does re. standard GWT-RPC (com.google.gwt.user.rpc), but it needs to do a bit more than that (namely: generate the serialization code for the client-side, as there's no reflection at runtime).
This going to be a hard task. I don't think the changing of serializers will work, GWT-RPC serializers are working with input as with a stream (basically data sent from server are in fact in JSON format, but they can be parsed only by GWT-RPC). You will have to create totally new generator, which will create code for parsing and object serialization/deserialization. AutoBean framework might be very helpful in this case. In the end you should be able to to migrate from GWT-RPC serialization to some other protocol without actually changing current code, which is using GWT-RPC services.
The biggest problem is cross-domain messaging. Normally you would use JSONP, but the problem is that JSONP basically allows only GET requests, if you need send a lot of data to the other server, you might not be able to fit everything into single requests. You can solve such problem with cross domain document messaging (e.g. you will open iframe, which will load special communication javascript from remote server, and you will use this iframe as proxy for your service via postMessage) , but this feature is not supported in IE7.
I have few questions regarding HornetQ:
What are differences between HornetQ core API and the JMS API ?
is there any advantage or disadvantage on using one of these ?
Is it true to say if I use the core API and then I decide to
change my Messaging Bus (let's say to ActiveMQ) then I have to
change all my codes ?
HornetQ Core API is a proprietary API from HornetQ, while the JMS API is a standard API defined by the Java Community Process.
There are a few features that are not supported on JMS API, that are available through core-api:
It's not possible to have multiple consumers on a single topic subscription (say if you wanted to have multiple consumers to scale it better)
It's more generic on how you create the subscription. You just create a queue within an address. Very simple.
We have a nice API for asynchronous confirmations. No need to block ever if you use this feature.
The advantage on the JMS is portability. Your code stays the same if you decide to move between providers.
The disadvantage on JMS is that it lacks some features and it's a bit verbose, what's under works on JMS 2 JSR right now.
Yes, because as I have said here, Hornetq-core api is a proprietary API, hence it will only work on HornetQ. The same way as some message systems will have a proprietary API.
If you encapsulate your Messaging access you can minimize that a lot though where you could just replace a single class on your system using standard OO techniques.