RESTful and HATEOAS Services: Revisited
Still not clear on the differences between RESTful and HATEOAS services? Read on for some clarity.
Join the DZone community and get the full member experience.Join For Free
I get a lot of traffic for my original article on RESTful and HATEOAS services, so I’ve decided to update and revise the article.
REST stands for Representational State Transfer. The main selling point of RESTful Services is that they are designed to be used on the internet using HTTP. It has the following constraints –
- Resources: Easily understood directory structure URI.
- Uniform Interface: Create, Retrieve, Update, Delete are accessed over HTTP via POST, GET, PUT, and DELETE methods.
- Messages: Most commonly these are JSON, but can be any format — HTML, XML, plain text, …
- Stateless: Interactions not stored, and state is handled in the request.
|PUT||Update or Create – Idempotent||PUT /customerservice/customers|
|PATCH||Update only – Idempotent||PATCH /customerservice/customers/1|
|DELETE||Remove record||DELETE /customerservice/customers/1|
The HTTP return codes are used for success/failure:
HATEOAS is an additional constraint on RESTful services. It requires the response to return the location of the data, and you can also return a list of other operations at that point. The advantage of this approach is that you can navigate the RESTful service model.
GET customerservice/customers/1 HTTP/1.1 HTTP/1.1 200 OK <?xml version=”1.0″?> <customer> <id>1</id> </customer>
Would have an additional link paramater to show its source
<?xml version=”1.0″?> <customer> <id>1</id> <link rel=”self” href=”http://localhost:8080/customerservice/customers/1″; /> </customer>
Published at DZone with permission of Martin Farrell, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.