Today I'd like to talk about what a makes an API a RESTful API. REST is an acronym for REpresentational State Transfer. That's it we're done here.
I'm kidding of course there is a bit more to discuss on the topic.
A REST API is an architectural style of an application program interface (API). An API in it's most general sense is how two pieces of software communicate between each other. An API has to adhere to certain principles to be considered to be RESTful. It's one of the most if not the most common style of web services on the web today, thanks to it being based on standard Hyper Text Transfer Protocol(HTTP) operations as well as its overall efficiency due to it using less bandwidth. Now I'm not going to be going super in depth about each part, that can be quite lengthy, but I want to impart a general idea of the makeup of a REST API.
What it's made up of
A REST API consists of a client and a server, resources, and HTTP request methods such as GET, POST, PUT/PATCH, and DELETE. The client will make requests to the server in the form of an HTTP request and the server will respond with the resources requested in the specified format JSON and XML being the most common.
The HTTP Requests broken down are:
GET - Sent to the server to retrieve specified resources.
POST - To add a resource to the server.
PUT/PATCH - To modify or update resources already on the server. A PUT being to completely replace the data a PATCH to modify existing data.
DELETE - removes specified resources.
The Six Constraints
So now that we have a very general idea of how it functions let's talk about the principles I mentioned earlier on what constitutes making an API RESTful. There are 6 architectural constraints that an API must follow:
Client-Server - There has to be a client to make the requests and a server to respond to the requests.
Uniform Interface (UI) - The interface between components should be the same or uniform in its structure. This is generally done using the standard HTTP Requests.
Stateless - All operations between the client to the server must be stateless. State is handled client side.
Caching - Resources are allowed to be cached unless otherwise specified.
Layered - The architecture allows for the servers to be layered.
Code on Demand - The server is able to send not only static data back but also executable code.
If an API follows all six of these constraints the API is then considered to be a REST API. Not too bad right.
The Benefits
I already briefly touched on the subject but what are the upsides of using or building a REST API? Well for one by separating concerns between the server and the client it improves scalability as well as implementation across different platforms. The fact that data is cacheable is a major upside as well because if the response is cached client side the request never even has to hit the server to fulfill the request it can instead reuse the cached data in certain cases. As mentioned earlier it's good on bandwidth and thus efficiency due to the responses from the server coming in the form of JSON or XML. It's a tried and true architectural approach behind building APIs and is dominant in the webs ecosystem so it's nice to have an idea as to what makes it up. I hope this brief overview leaves you with a general idea of what makes an API RESTful.
As always, thanks for checking this post out if you did and I hope you learned something along the way. Happy Coding!
Top comments (0)