Resources :
Roy Fielding
- http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
- http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
Martin Fowler
- https://martinfowler.com/articles/richardsonMaturityModel.html
- http://www.rgoarchitects.com/Files/fallacies.pdf
Digest :
Comparasion :
- RPC API
- Message API
- Resource API
Representational State Transfer
- Application States Transfer among the Resource's Representation
- Application States : stem from Resource State;
- Representation : Representation of Resources - format;
- Transfer : between Client and Server;
- Uniform Interface :
Constaints | Description | OO |
---|---|---|
| URI = Object Reference Resource = Object | Class/Object |
| A representation of resource in a particular format, XML, JSON, CSV, etc | Collection of Fields |
| Metadata sent back to client to intepret the response, also the info needed for making next call | |
| Connectedness/linkage; | List of Methods: What method that a object can invoke, on the provided fields, etc; |
- Stateless : client, rather than server, maintain all the necessary info for making the next request;
Maturity Level :
RMM, while a good way to think about what the elements of REST, is not a definition of levels of REST itself. Roy Fielding has made it clear that level 3 RMM is a pre-condition of REST.
Level | Definition | Explaination |
---|---|---|
0 | HTTP merely used as transport prorocol | like RPI, method, format, response, are all up to users to define |
1 | Resources | tackles the question of handling complexity by using divide and conquer, breaking a large service endpoint down into multiple resources. |
2 | Leverage HTTP Verbs and Response Code | introduces a standard set of verbs so that we handle similar situations in the same way, removing unnecessary variation. |
3 | Hypermedia Controls | introduces discoverability, providing a way of making a protocol more self-documenting. |