REST stands for . It is a that defines a set of constraints or rules that you should adhere to when you are creating your APIs. Representational State Transfer software architectural style Well, when the APIs are conformed to these constraints, they are called RESTful APIs. What about 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 (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. Client — Server separation : 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 Uniform interface here — 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 Statelessness — Response provided by the server is cacheable or not (usually checked by version number) Cacheability — 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 Layered System — Optional constraint, the server can provide executable code (scripts) to the client on demand Code on demand If you are interested, you can read more about these constraints here With REST most commonly used means of communication is via . Let’s take a look at what the HTTP Request looks like - HTTP : this is where you are making the request from. ex: Base URI https://jsonplaceholder.typicode.com/todos/1 : what operation you are performing (GET, POST etc..) HTTP Methods : additional information passed to the client and server (ex: authentication, content-type etc..) Headers : optional data/body to provide with the request Body We covered HTTP methods briefly above, let’s go over them a little bit more. and it maps the following way: REST HTTP Methods follow CRUD operations — creates a new resource (adds a new entry in the database) POST (Create) — most commonly used to fetch/retrieve data GET (Read) — used to update a resource (edits an existing entry in the database) PUT/PATCH (Update) — delete a resource from the server (delete the entry from the database) DELETE (Delete) Check out the video below to see a real API example to better understand the above topics Follow on Twitter for latest updates @automationbro Subscribe to my channel to see more content like this YouTube Previously published at https://dev.to/automationbro/what-is-a-rest-api-1im9

Fetch

Twitter

YouTube

Check out my YouTube channel

Read My Stories

Too Long; Didn't Read

In your car, at home, or at work — Bosch technology shapes many areas of life.

A Quick Introduction to REST API

Too Long; Didn't Read

Companies Mentioned

Automation Bro

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

A Quick Introduction to REST API

Too Long; Didn't Read

Companies Mentioned

Automation Bro

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES