Styles and the Design of Network-based Software Architectures, Doctoral dissertation, University of California, Irvine no implementation details goals constraints → REST + HTTP REST × SOAP et al. 4/154
of resources through these representations representation and it's metadata = enough information to manipulate it • self-descriptive messages each message = enough information to process it (MIME, cache, ...) • hypermedia as the engine of application state HATEOAS, hyperlinks, hypertext 7/154
You’re using HTTP to make RPC calls. HTTP is only really used as a tunnel. 2.Resources Rather than making every call to a service endpoint, you have multiple endpoints that are used to represent resources, and you’re talking to them. 3.HTTP verbs You interact with resources using HTTP verbs, rather than always using POST. 4.HATEOAS Hypermedia Controls. HATEOAS. You’re 100% REST compliant. 9/154
can do whatever you need just by inspecting the API • transitions are made by hyperlinks – URIs • abstracting away implementation details iOS apps Sounds familiar? Yes, it's exactly how HTML and websites work.
API clients will love you. Look at Django REST framework's browsable APIs. • It is the future. (Everyone says it, so it must be true.) HTTP2.0 solves the biggest flaws. HTTP2.0 async, multiplexing, compression, pipelining, etc. → • Designed for scale. Everything is designed for massive caching and counts with presence of middleware. • Change tolerant. Change business logic in a single place! Without the links the client must implement logic for building links. If you put this code inside your iPhone or Android clients you cannot change the URI structure on the server without breaking existing clients. If a link is present the client can follow the link. A client application does not have to repeat the business logic for deciding if a book can be purchased or downloaded. • URIs are implementation detail. Choose a URI naming scheme that fits whatever framework or coding conventions that we find useful. 150/154