HATEOAS API: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
No edit summary |
||
| Line 3: | Line 3: | ||
It distinguishes itself from other APIs by having the following properties: | It distinguishes itself from other APIs by having the following properties: | ||
* Heavy use of [[Media Types]] to allow [[Backward Compatibility]]. | * Heavy use of [[Media Types]] to allow [[Backward Compatibility]]. | ||
* It does not allow clients to construct [[URL | URLs]] (unless instructed by the server to do so) to allow for applications to change their URL structure. | * It does not allow clients to construct [[URL | URLs]] (unless [[URL Templating | instructed by the server to do so]]) to allow for applications to change their URL structure. | ||
* Other than an entry URL and a set of documents describing the [[Media Types]], no additional knowledge should be necessary to use the API. | * Other than an entry URL and a set of documents describing the [[Media Types]], no additional knowledge should be necessary to use the API. | ||
Revision as of 05:24, 17 September 2020
Originally called REST, HATEOAS is a way of designing HTTP APIs as described in Roy Fieldings thesis. The acronym stands for Hypermedia as the Engine of Application State.
It distinguishes itself from other APIs by having the following properties:
- Heavy use of Media Types to allow Backward Compatibility.
- It does not allow clients to construct URLs (unless instructed by the server to do so) to allow for applications to change their URL structure.
- Other than an entry URL and a set of documents describing the Media Types, no additional knowledge should be necessary to use the API.
HATEOAS APIs usually make heavy use of HTTP features like:
- Caching to enable the application to scale better.
- Content Negotiation to support older clients and give users localized versions of resources.
- Conditional PUTs to add Optimistic Concurrency.