REST - KeynesYouDigIt/Knowledge GitHub Wiki
REST in theory
REpresentational State Transfer (REST) is a set of architectural principals that were key for the WWW, and describe how a distributed interactive media[^1] system should behave.
REST came from Roy Fielding's dissertation. My notes - Roy Fielding REST dissertation
The following is a vastly oversimplified personal summary.
REST is focused heavily on Statelessness - Agents (often clients and servers) send messages back and forth that do not require the retention of context to understand. For example, a server does not need to hold the concept of a session and a connection to understand which client messages are coming from. a client ID is sent with each request. The client can cache this information if needed (caching is often encouraged in REST where appropriate, usually as defined by the server).
REST is also heavily focused on Separation of Concerns - REST often uses a server-client relationship to convey points, and states that systems should be "layered" - if a message is sent between nodes, and another node is between them (like a load-balancer or authorizer) the client does not have to know about or interact in a special way with this middle node. This ties closely to the principal below...
REST is also heavily focused on each Layer of a system having a Uniform Interface. A server returning a request should represent the data in a consistent way, regardless of how the data is stored and if the storage changes internally. Clients should then be able to manipulate resources through representations with the same or a similar structure (same file format, same data structure, etc). No seperate requests, new formats, or additional information needed by either party.
I believe these 3 principles are the most often discussed of the six major constraints. See more here
REST in modern practice - for the web and web developers
While REST is key in the original design of the web, when referenced in modern web development, RESTful practices describe precisely how web APIs should use HTTP in a way that conforms well to RESTful principals. Requests to URIs state what they would like to do with the resource using HTTP's methods (GET, POST, etc) and responses represent the resource in its original state (when retrieved using GET) or new state (changed using POST, PUT, PATCH, potentially others).
Some good thoughts comparing REST and it's related pieces in the context of Data Engingeering
Is GraphQL really "not" REST? or is it a new implementation?