REST
Representational state transfer is a set of standards which allow applications to communicate over the internet using HTTP. They don't have to be web based. RESTful servers are performant, scalable, simple, modifiable, visible, portable, and reliable. A server must obey the six constraints listed below in order to be RESTful (and to gain the desired attributes above).
- Client-server architecture: These two concerns are separate, meaning the client side application cannot directly access the server's memory or database. This greatly simplifies the server, and also allows for multiple user interfaces across multiple platforms. For example, you can have a React app, an iOS app, and an Android app all use the same backend.
- Statelessness: No client context is stored between requests. All requests are independent of each other and contain all of the necessary information to make the request, so the client doesn't need to go through a set of steps to get to a certain point.
- Cacheability: It uses HTTP's caching system to reuse fresh data, or to prevent reusing stale data, thus eliminating some client-server interactions and boosting performance.
- Layer system: Intermediary servers, which enforce security policies and improve scalability with load balancing and caching, can be used, but the client shouldn't normally be aware if them.
- Code on demand (optional): Servers can push executable code to a client.
- Uniform interface: How the client-server interface is defined:
- Resource identification in requests: URIs are used to identify particular resources. The server also won't send over an internal representation of the requested data (it won't send the whole database), it'll instead send an HTML or JSON representation.
- Resource manipulation through representations: when a client has a representation of a resource, it can modify or delete the resource (if it is permitted).
- Self-descriptive messages: Messages include information on how to processes the message. It'll say it's in JSON, for example.
- Hypermedia as the engine of application state (HATEOAS): Users should be able to get everywhere they need to go using hyperlinks. They shouldn't have to manipulate URIs to navigate through a web application. It should get a tree of links it can navigate anywhere to.
URLs and HTTP methods:
Collections:
Collections will identify the full or partial resource. For example http://api.example.com/users may identify some or all of the users in a database. What data is actually returned will depend on the server's implementation and the permissions of the client.
- GET: Will provide URI's to the resources for each individual member of the collection, plus some other details most likely.
- PUT: Can replace the entire collection with another collection.
- PATCH: Not used for collections.
- POST: Create a new entry in the collection. Should automatically assign the new entry's URI and return it in the response.
- DELETE: Delete the entire collection
Element:
An individual member of a collection. For example http://api.example.com/users/17 may identify the user with ID 17 (IDs don't need to be integers, and often shouldn't be).
- GET: Will return a representation of the addressed member of the collection.
- PUT: Replaces the member with a new one, or it will create one.
- PATCH: Updates the member.
- POST: Not used. POST to the collection instead.
- DELETE: Delete the member.