We use org.json api to parse json on server side and GWT JsonParser to parse JSON on client side. Is there a api that we can use that can be used on both the client side and server side?
You are looking for GWT AutoBean: http://code.google.com/p/google-web-toolkit/wiki/AutoBean
With AutoBeans you juset define the structure of your JSON and the GWT Compiler handles the rest.
I am writing this in comparison to using autobeans or GWT-RCP - if you are using Java on the server. Especially so, if you are not.
The cleanest way is REST-RPC/JPA, where you can share a single set of POJOS between client, server and persistence db. Let me brag on behalf of this technology mix - one single set of POJOs, instead of three, without any (or minimal) transformation between the three fronts.
You should not have to write any data transformation routines. Or at least, only minimal amount of data transformation due to serialization constraints or because you are trying to interface GWT and REST with an existing schema which presents a high degree of non-serializability.
As well as, similar to GWT-RPC, sharing a single set of Java RPC methods on both client-server sides. Well, nearly the same set of methods. Except that the return type on the server-side becomes the callback generic parameter on the client-side.
The mix of technology is:
JAX-RS (either Resteasy or Jersey on the server side)
JAX-RS + GWT = RestyGWT on the client-side
JPA on the server-side
JAXB over JAX-RS on both GWT client and server-side.
Jackson JSON processor on server-side.
Compelling reasons for REST-RPC is
you could pretend you writing client-server conversations as GWT-RPC. The service interface and callback attitude is the same.
The data interchange between client and server is in JSON.
Which means you could use a browser instead of your GWT client to converse with the server after you have successfully set up your app. Or jQuery. Or PHP, or Python as the server.
no need to muck around with the JSON or XML encode/decode yourself - deal in POJO and only in POJO.
you could use the browser to debug your web service independent of the GWT client.
The attitude of REST is (besides state independent requests) is the concept called a Web API. An API like a javadoc, perhaps - but stated in terms of JSON or XML. The wonderful thing about this API is - you do not have to generate the documentation. Like a javadoc, you could run Enunciate over the service interface.
You could follow my discussion in the following (3+ part) blog post:
http://h2g2java.blessedgeek.com/2012/07/gwt-with-jax-rs-and-jpa-part-3.html.
Related
I'm struggling with Java8 streams.
Need to read list of JSON objects from external REST service and unmarshall it to POJOs
What is the best approach for it?
Use JAX-RS client like Jersey or RESTEasy for that and don't bother using Java8 streams unless you there is a very specific reason for doing that (if you have one - please post it here).
I have been working Rest and json using spring framework.
I have got couple of doubts.
1)Is http transferring data in the form of json can be called Rest.I know http is protocol and Rest is architectural style?
2)Can any application (url) that accepts data in the form of json(sent from any client) called Rest?
2)why soap protocal is using http under the hood?
ReST is an architectural style which is completely independent of either HTTP or JSON. ReST really only talks about modelling a domain as a set of 'resources'. Any resource has a unique identifier which distinguishes it from other resources. Clients interact with resources using a common protocol and resources are created / modified / deleted through manipulating their representations.
HTTP and JSON are both aspects of specific implementations of a ReSTful architecture. HTTP is a good transport mechanism for ReSTful applications, providing a common API in the form of HTTP's set of verbs - GET, PUT, POST, DELETE. JSON is a good document transfer format and so is often used to implement the 'representation' aspect of ReST, but ReSTful applications can use other document formats if they choose - you can find ReSTful applications which use XML, JPEG, AVI, MP3, ...
Neither HTTP nor JSON is specifically ReSTful and its entirely possible to find HTTP applications using JSON which are not ReSTful at all. Similarly, not every ReSTful application will use JSON or HTTP (although I've never seen a real application in the wild which doesn't use HTTP/HTTPS).
Rest is not all about JSON, you have also the verbs GET, POST, PUT, DELETE and the http code for your answers which are involved.
If you post JSON for every action then it's not restful
In REST everything is a resource.
HTTP is an application layer. It's has nothing really with REST concept. You see a webpage via http and this is not REST at all. So SOAP can also use http.
HTTP is not bind to REST but REST is bind to HTTP
As stated in other comments, RESTful is an architecture, but not a language or coding paradigm.
RESTful:
Something anti-REST would be JSON-RPC (https://github.com/ethereum/wiki/wiki/JSON-RPC). The Framework is a Remote Procedure Call Lib. JSON-RPC would definitely not be RESTful since the RPC layer maps urls to functions (i.e. verbs) rather than particular resources (i.e. nouns). So rather than POSTing to some resource, you are calling a method, yet JSON as the format to serialize the data. There are tradeoffs to each. It just so happens RESTful APIs are very common for public ones as many believe documentation can be clearer to outsiders.
JSON:
On the other hand, one could develop a RESTful architecture and not use JSON. There are many serialization libs, each with tradeoffs such as compression and schema-less vs something closer to type safety. Examples besides JSON would include MessagePack and Google's ProtoBufs. Of coarse, you could even use XML, although uncommon with RESTful APIs. JSON is used a lot in public APIs since pretty much any language can do JSON serialization with low 3rd party over head (i.e. not importing specific libs)
I'm attempting to query an REST service with fairly limited idea of how to approach it.
I'm using Delphi XE6 (upd 1)
The company providing the API have said that: "The API is implemented as JSON via SSL"
and they go on to say that:
Access to any API endpoint requires authentication via signed requests, created with publicand secret API
keys
I have the keys defined above.
The signature is an HMACSHA256 hash of a string containing the request contenttype, host,
URL, date timestamp (matching the request Date header) and request content (eg POST
parameters) separated by a single newline, and passed with the public key in a custom header
XAPIAuthorization along with the public key, in the format PUBLICKEY:SIGNATURE
I understand each request needs to be signed.
How do I sign an http request with Delphi XE6?
The confusion for me at the moment is it seems Delphi has a number of built-in components have accessing RSET servers and parsing the JSON returned. I can't see any obvious way of signing requests using these components.
Specifically is there any help from the built-in Rest components or do I have to provide my own solution?
I'm want to try changing a SOAP WCF to accept requests and return results in JSON format to make the data traffic less bulky.
I see that JSON requests functions looks like this:
wcfClient.OpenReadAsync(http://yourUrl.com/wcf/service1.svc/GetEmployees)
and do the regular SOAP requests functions instead that looks like :
wcfClient.GetEmployeesAsync();
1) For JSON results, do you need to parse them into an object or is it automatically parsed like SOAP?
2) Is there a way to do this without doing too much work like changing every single WCF calls in the project to looks "JSON-ish"?
To complement Davut's answer - WCF does support building RESTful services, although I agree that the ASP.NET Web API framework in general easier to use than WCF. JSON.NET is a great library, and it has nice deserialization capabilities (e.g., it can easily take the JSON which represent the list of Employee objects and convert them into the actual List<Employee> instance)
But for completeness sake, if you want to use a "normal" WCF client to access WCF-based services which return JSON, you can do it. It's not too straightforward, but you can do that by using a new encoder and behavior which does the conversion. The post at http://blogs.msdn.com/b/carlosfigueira/archive/2010/04/29/consuming-rest-json-services-in-silverlight-4.aspx talks more about it, and has a pointer to a code sample.
In short, it's possible to consume JSON using a WCF client in Silverlight, but due to its complexity it's usually not done, and Davut's option (use a HTTP client such as WebClient to download JSON, then a library such as JSON.NET to parse it into objects) is preferred.
Firstly the idea "make the data traffic less bulky." is good.
Especially for Mobile devices. Beside this don't think that WCF xml causes network issues for PC. XM is the one of most compressible format. By WCF binary it goes as compressed.
For "Is there a way to do this without doing too much work?"
Yes there is a way name on it RESTFul Services(Restless Services). Now Microsoft directly support it by WEBApi.
Also you may use ODATA for filtering,ordering operations
Here are some links,
http://msdn.microsoft.com/en-us/library/system.servicemodel.web.webgetattribute.aspx
http://blogs.msdn.com/b/rjacobs/archive/2010/06/14/how-to-do-api-key-verification-for-rest-services-in-net-4.aspx
ODATA
http://www.odata.org/documentation/uri-conventions#FilterSystemQueryOption
A few practice notes,Some restrictions:
EntityFrameWork entities derived from EntityObject which has IsReferenceType attribute doesn't allow you to JSON serialize. ( I produced POCO objects using an automapper mapped them and serialized json)
WEBAPI support you much think such as WebGet,WebInvoke GetXML Give JSON ,ODATA features(just select and format not allowed.)
Note:In your web request's header you should accept text/json to get really json.
"For JSON results, do you need to parse them into an object or..."
I can say you should try JSON.NET it's portable library works everywhere. When you deserialize with a generic function it returns you the collection you expect.
Hope it helps someone. While discovering these stackoverflow helped me like an assistant.
Our project makes use of gilead to pass model objects to the client side using the GWT RPC model. The problem we face is that serializing to and from JSON on the client side for procesing is becoming more of an issue as our model grows / changes.
I am considering using Overlay Types as our client side representation of our entity objects.
What is the general approach for this when using it in conjunction with Hibernate, do you have to recreate the objects server side and then persist ?
Would it be possible to pass the client side object back and then use Dozer to map to the server side Entity ?
Thanks,
Andros
With Gilead and GWT-RPC, you don't need to translate your objects to JSON at all. You just pass your objects (entities which extend net.sf.gilead.pojo.gwt.LightEntity) to the client, and use them directly on the client. You can also send these objects from the client to the server. I would recommend to look at the Gilead example in this article:
http://code.google.com/webtoolkit/articles/using_gwt_with_hibernate.html
You can download the source code here:
http://google-web-toolkit.googlecode.com/files/gwt_hibernate_gilead.zip