REST stands for Representational State Transfer. It is a software architectural style that defines a set of constraints or rules that you should adhere to when you are creating your APIs.
What about RESTful APIs? Well, when the APIs are conformed to these constraints, they are called RESTful APIs.
REST sets up a standard that makes it easier to use those APIs and anyone (ex: developer) familiar with these standards can quickly start using these APIs.
Let’s go over some of these architectural constraints:
- Client — Server separation: Client (let’s say your browser) and server shouldn’t depend on each other, they should act independently and communication should only happen using request which only Client should be able to make. Server shouldn’t send the client information which hasn’t even been requested. So basically the main principle behind this is having the separation of concerns between Client and the Server.
- Uniform interface: Client and Server should provide all the necessary info to each other so both can act upon the data accordingly, for example — request should contain resource identifier i.e the endpoint when making a request. There are also some other constraints for this, you can read more about it here
- Statelessness — Server should not store any info about the user using that API. So every time a request is made by the client, it will need to contain all the info required for the server to provide you with a proper response. Even if the request is made 100 times server wouldn’t remember that so its client’s responsibility to send all the relevant data to the server
- Cacheability — Response provided by the server is cacheable or not (usually checked by version number)
- Layered System — there could be many other layers (proxy or load-balancer) between client and servers but it shouldn’t affect the request or response in any way
- Code on demand — Optional constraint, the server can provide executable code (scripts) to the client on demand
If you are interested, you can read more about these constraints here
With REST most commonly used means of communication is via HTTP. Let’s take a look at what the HTTP Request looks like -
- Base URI: this is where you are making the request from. ex: https://jsonplaceholder.typicode.com/todos/1
- HTTP Methods: what operation you are performing (GET, POST etc..)
- Headers: additional information passed to the client and server (ex: authentication, content-type etc..)
- Body: optional data/body to provide with the request
We covered HTTP methods briefly above, let’s go over them a little bit more. REST HTTP Methods follow CRUD operations and it maps the following way:
- POST (Create) — creates a new resource (adds a new entry in the database)
- GET (Read) — most commonly used to fetch/retrieve data
- PUT/PATCH (Update) — used to update a resource (edits an existing entry in the database)
- DELETE (Delete) — delete a resource from the server (delete the entry from the database)
Check out the video below to see a real API example to better understand the above topics
Follow @automationbro on Twitter for latest updates
Subscribe to my YouTube channel to see more content like this
Previously published at https://dev.to/automationbro/what-is-a-rest-api-1im9