Roy Fielding, the author of REST, made it clear on this blog post: REST APIs must be hypertext-driven. If your clients are building URIs from templates in documentation and not getting links in the resource representations, that's not REST. This last point can't be emphasized enough. That's nonsense, but that's what many people think REST is. If we designed the web the way people think REST should be done, instead of having a home page with links to Questions and Answers, we'd have a static documentation explaining that in order to view a question, you have to take the URI /questions/, replace id with the Question.id and paste that on your browser. When you enter Stack Overflow, you know what a User, a Question and an Answer are, you know the media types, and the website provides you with the links to them. REST is the architectural style of the web itself. They are not only documenting something that's supposed to be following the standard, but when you do that, you're coupling the client to one particular moment in the evolution of the API, and any changes on the API have to be documented and applied, or it will break. Those fancy documentation generators that give URI patterns for everything you can do in a REST API miss the point completely. This means that a client only knows the entry point URI and the resources are supposed to return links the client should follow. REST is not REST without hypermedia and HATEOAS. Security and authentication in HTTP are standardized, so that's what you use when doing REST over HTTP. REST is as standardized as the parts you're using. Read this answer for a detailed explanation on that. REST is not a mapping of CRUD to HTTP methods. Pretty much like you can follow an ftp link on a website, a REST application can use any protocol for which there is a standardized URI scheme. I think these are the crucial points to understand what REST is about, and how it differs from SOAP: Additionally, a REST client can be extended by code-on-demand supplied by the server itself, the classical example being JavaScript code used to drive the interaction with another service on the client-side. In SOAP, the client needs previous knowledge on everything it will be using, or it won't even begin the interaction. A client is supposed to enter a REST service with zero knowledge of the API, except for the entry point and the media type. If done right, there's less coupling, and changes can be dealt with more gracefully. You don't violate the protocol standards by creating extra methods, you leverage on the standard methods and create the actions with them on your media type. It's a generic client that knows how to use a protocol and standardized methods, and an application has to fit inside that. You need constant updates following any change, but it's easier to ascertain if the contract is being followed.Ī REST client is more like a browser. There's a rigid contract between client and server, and everything is expected to break if either side changes anything. A SOAP client works like a custom desktop application, tightly coupled to the server. Pushing things a little and trying to establish a comparison, the main difference between SOAP and REST is the degree of coupling between client and server implementations. This is probably one of the sources of confusion around it, since people tend to call REST any HTTP API that isn't SOAP. SOAP and REST can't be compared directly, since the first is a protocol (or at least tries to be) and the second is an architectural style. Not only your question and the answer by reflect those, but most of the questions and answers related to the subject on Stack Overflow. Unfortunately, there are a lot of misinformation and misconceptions around REST.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |