Is it RESTful, or simply RPC?
"Pretty URLs like /employees/3 aren’t REST.
Merely using GET, POST, etc. aren’t REST.
Having all the CRUD operations laid out aren’t REST.
In fact, what we have built so far is better described as RPC (Remote Procedure Call)...
What needs to be done to make the REST architectural style clear on the notion that hypertext is a constraint? In other words, if the engine of application state (and hence the API) is not being driven by hypertext, then it cannot be RESTful and cannot be a REST API. Period. Is there some broken manual somewhere that needs to be fixed?
of NOT including hypermedia in our representations is that clients MUST hard code URIs to navigate the API. This leads to the same brittle nature that predated the rise of e-commerce on the web. It’s a signal that our JSON output needs a little help.
Introducing Spring HATEOAS (Hypermedia as the Engine of Application State), a Spring project aimed at helping you write hypermedia-driven outputs."
Read here: https://spring.io/guides/tutorials/bookmarks/
Merely using GET, POST, etc. aren’t REST.
Having all the CRUD operations laid out aren’t REST.
In fact, what we have built so far is better described as RPC (Remote Procedure Call)...
What needs to be done to make the REST architectural style clear on the notion that hypertext is a constraint? In other words, if the engine of application state (and hence the API) is not being driven by hypertext, then it cannot be RESTful and cannot be a REST API. Period. Is there some broken manual somewhere that needs to be fixed?
of NOT including hypermedia in our representations is that clients MUST hard code URIs to navigate the API. This leads to the same brittle nature that predated the rise of e-commerce on the web. It’s a signal that our JSON output needs a little help.
Introducing Spring HATEOAS (Hypermedia as the Engine of Application State), a Spring project aimed at helping you write hypermedia-driven outputs."
Read here: https://spring.io/guides/tutorials/bookmarks/