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)
Related
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 new to REST Web based services and trying to understanding how the contract is created for JSON returned REST services.
From my understanding, any XML based SOAP/REST services will have a WSDL document.
What document is created for JSON based REST Services?
a REST web service doesn't have any auto explanation document like wsdl, you need to know how the webservice works, reading the documentation provided with it. Generally it works with common requests. Assuming that you have a products REST webservice, you could have:
GET /products -> read all products
GET /products/1 -> read the product 1
POST /products -> create a new product
PUT /products/1 -> update product 1
DELETE /products/1 -> delete product 1
but you have to know which parameters you need to send to any request. I hope I was clear...
Every HTTP response has metadata in HTTP headers. One of those HTTP headers is ContentType. The content type identifies a media type which is the contract that the response payload must conform to. The specifications for media types can be found here http://www.iana.org/assignments/media-types/media-types.xhtml
One of the major differences between SOAP and HTTP (as an application protocol) is that SOAP defines the contract at design time, whereas with HTTP the contract is specified in the response message so it can change over time. Therefore it is important for the client to read the content type on each response to know how to process the response.
There is WADL (http://en.wikipedia.org/wiki/Web_Application_Description_Language) although it is not so much used as WSDL for SOAP. REST services written in Java EE automatically generate it as .../application.wadl, PHP suppor is pretty poor as far as I know.
As the others mentioned a web service definition is not necessary for RESTful services, however if you want to create something similar for your API the industry standard is Swagger/OpenAPI, though GraphQL schemas are also becoming a defacto standard too.
There are also a few other options you can also explore (see wikipedia).
Here is a list of the most common options:
swagger.json or openapi.json files in the OpenAPI Spec
GraphQL Schemas with full spec here
Postman Collections which can be published online.
RAML
RSDL
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.
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.
We're having a bit of a discussion on the subject of posting data to a REST endpoint. Since the objects are quite complex, the easiest solution is to simply serialize them as JSON and send this in the request body.
Now the question is this: Is this kosher? Or should the JSON be set as a form parameter like data=[JSON]? Or is sending of JSON in the request body just frowned upon for forcing the clients using the application, to send their data via JavaScript instead of letting the browser package it up as application/x-www-form-urlencoded?
I know all three options work. But which are OK? Or at least recommended?
I'd say that both methods will work well
it's important that you stay consistent across your APIs. The option I would personally choose is simply sending the content as application/json.
POST doesn't force you to use application/x-www-form-urlencoded - it's simply something that's used a lot because it's what webbrowsers use.
There is nothing wrong about sending it directly as serialized JSON, for example google does this by default in it's volley library (which obviously is their recommended REST library for android).
If fact, there are plenty of questions on SO about how not to use JSON, but rather perform "normal" POST requests with volley. Which is a bit counter intuitive for beginners, having to overwrite it's base class' getParams() method.
But google having it's own REST library doing this by default, would be my indicator that it is OK.
You can use JSON as part of the request data as the OP had stated all three options work.
The OP needs to support JSON input as it had to support contain complex structural content. However, think of it this way... are you making a request to do something or are you just sending what is basically document data and you just happen to use the POST operation as the equivalent of create new entry.
That being the case, what you have is basically a resource endpoint with CRUDL semantics. Following up on that you're actually not limited to application/json but any type that the resource endpoint is supposed to handle.
For non-resource endpoints
I find that (specifically for JAX-RS) the application/x-www-urlencoded one is better.
Consistency with OAuth 2.0 and OpenID Connect, they use application/x-www-urlencoded.
Easier to annotate the individual fields using Swagger Annotations
Swagger provides more defaults.
Postman generates a nice form for you to fill out and makes things easier to test.
Examples of non-resource endpoints:
Authentication
Authorization
Simple Search (though I would use GET on this one)
Non-simple search where there are many criteria
Sending a message/document (though I would also consider multipart/form-data so I can pass meta data along with the content, but JAX-RS does not have a standard for this one Jersey and RestEasy have their own implementations)