Client-server architecture
The API defines all communication between the client and the server, which are separate components and free to be developed independently.
Layered system
The client is indifferent to whether it is communicating directly or indirectly with the server.
Cacheability
A response can be cached if the same request will return the same result and have no side effects. Being able to cache responses and avoid revisiting the server improves scalability. The API should make clear which responses can be cached.
Uniform interface
The brief idea is that the API comprises resources. Each request from the client specifies a resource and an action. Requests must be self-contained so that the server can respond without getting additional information from the client. For example, rather than setting up a connection that assumes a language and a timezone, every request will include the language and timezone. This repeated information adds some communication overhead but pays off by making it easier for the server to handle requests. Also, the server must report which resources and actions are available. A uniform interface aligns with HTTP methods like GET, PUT, and POST.
Statelessness
Statelessness means that the server does not need to store any client-specific information. This is a common subject for confusion since it seems to imply that keeping track of, say, objects in a shopping cart would require the maintenance and management of that information on the server. However, this is not the case. A distinction is made between the server that processes the request and the data store that keeps the relevant information. The obvious solution is that the request provides user and session identifiers that the server can use to fetch the relevant information from the data store. Cryptographic operations can sometimes be used to let the server evaluate the correctness of a request without having to access the data store, or any other service.