Basics Of REST APIs
In this blog, we are going to cover the basics of the REST APIs and the end will focus on some of the popular questions related to it.
What are APIs?
API stands for Application Programming Interface. In Lehmann terms, an API is a connection with a resource that allows us to communicate, create, modify or delete the resource. In terms of computers, an API is a software interface through with we can connect and perform a CRUD(Create, Read, Update and Delete) operation on our resources(databases). An API following REST styles are REST APIs. There are also RPC APIs and SOAP APIs.
What do REST APIs mean?
Let’s begin with REST, REST means Representational State Transfer. It is basically an architectural style for the Distributed System. There are certain rules or we can call them principals that need to be followed for developing the REST or RESTfull APIs.
The term REST was first coined by Dr. Roy Fielding in 2000. Roy is a computer scientist and is the co-founder of the Apache HTTP server project.
REST is a style not an architecture or a protocol to be followed, this is the main thing to be kept in mind while designing REST APIs. There can be a scenario where the APIs are not following all the styles that are mentioned for the RESTful APIs, but still, they are called REST APIs, this is the beauty of being called a style rather than a protocol.
The biggest advantage of using the RESTfull style is that it is an open standard. There is no need to bind it to a certain language or protocol. Client and Server can always be decoupled, i.e. client can be on React while the server can be on Python. Let’s take a look at the designing principles for the RESTfull style.
Guidelines for the RESTfull style-
Stateless means that the APIs should be independent of any other API and that every API should act as a single entity that is decoupled from other APIs irrespective of being used in the same project. This can be achieved by bypassing all the necessary information in the API call, with the URL. Client and server are thus independent of each other and APIs can be made out generic, that is that they can be used by any client or can also be served as a separate entity by exposing the APIs. It results in a highly scalable architecture.
Every resource present between the client and the server must be identified uniquely. Having a uniform interface helps in the decoupling of the client and the server. HTTP verbs are used on the REST APIs that are using HTTP protocols, some of the most widely used verbs –
GET- GET requests are used to retrieve the resource information as per the request made from the client with the specified URI. Query parameters are passed with the URL. GET requests can be cached and bookmarked. No sensitive information should be passed in the GET URL, as it can lead to a data leak. There is a limitation to the length of the data.
POST- The main purpose of the POST request is to create a new resource at the requested URI, or we can say to insert a new record. Request Body is used to get the resource information that needs to be created. Apart from creating a new resource POST can be used to update, get or delete a resource also. But that does not come into the right practice. POST APIs cannot be cached and bookmarked. There is no limitation to the length of the data.
PUT- PUT is used to create or update a resource. The main purpose is to update the resource. The main difference between the PUT and POST is idempotent. PUT requests are idempotent, i.e. calling the PUT request multiple times will not result in updating or creating the data multiple times, while for POST it can result in creating the number of resources equal to the number of the times it is called.
PATCH- In a PATCH request, only a part of the resource is updated as compared to PUT where the full resource is being updated.
Delete- Delete request is used to delete the resources.
Option- Option requests are used to describe the communication options for the resource.
Head- Head requests are similar to the GET request but with no return body in the response. The main purpose is to check what the GET request will return before hitting it.
Connect- Connect requests are used to create a tunnel with the resource. That is to start two-way communication.
REST APIs should be holding a flag or a label that should tell the client whether the caching is allowed or not. If the flag is marked as true, then the client has the right to reuse the information of the response in future references.
Every REST API should have a unique URI. URI means Uniform Resource Identifier. That is a character of strings that identifies a resource.
Layered System Architecture
Every resource must fall in a layer, and cannot interact beyond that layer.
UI (User Interface) and Backend(APIs) must be decoupled from each other. There should not be any dependency between them, this results in a scalable environment where both UI and backend can serve as a separate entity.
So, these are the guidelines that must be kept in mind while developing a REST API.
Questions asked for REST APIs
q1. While dealing with JWT(JSON web token), what is a claim?
ans. Data in the token is the claim
q2. What are webhooks used for?
ans. To notify other systems of an event
q3. What is CORS used for?
ans. CORS is used to allow the browser on another site to make an AJAX request to your API.
q4. What is the main purpose of an API?
ans. To share the features and functionality with other systems.
q5. What is a CURL?
ans. CURL is a command-line tool for using or hitting an API.
q6. What is a Swagger?
ans. Swagger is a modern specification for describing an API.
q7. Why server-side caching is preferred?
ans. It reduces the load on the server
q8. What is an OpenID Connect?
ans. It is an identified layer on top of the OAuth 2.0
q9. Why GraphQL is preferred over REST approaches?
ans. It provides the flexibility of querying responses, thus reducing the load on the server-side.
q10. Why is stateless used as a constraint?
ans. It specifies that there should be no shared context.
q11. What is the purpose of a User-Agent?
as. It identifies the SDK or the client application.
q12. What is the advantage of OAuth over the API Key method?
ans. A token is scope to a specific use case in OAuth.
q13. What is API Proxy?
ans. It is used to wrap legacy architecture or protocols into a REST interface for easier consumption and integration.
q14. What protection does a JWT offer to mitigate tampering with its contents?
q15. Why is privately used in a Cache-Control response header?
ans. To specify that a response should not be stored in a private cache.
q16. What is a client-server constraint?
ans. It allows caching, routing, and other systems between client and server.
q17. Using OAuth, what scope would you request for write access to the API?
q18.Which metric tracks the overall availability for your API?
q19. Which response header tells the client that the response is not to be cached anywhere?
ans. Cache-Control: no-store
q20. What is the benefit of using an API Gateway?
That’s it for now, thanks for reading.
Let me know if you have any questions.