API stands for Application Programming Interface. If any software with a distinct function can be referred to as an application, the interface acts like a contract of service between two applications. There are requests and responses that are used to communicate. By using the API documentation, everyone can gain insights into how to work with APIs.
Basically the APIs are the mechanisms that are used to communicate between two software components using a set of definitions and protocols. For example your mobile phone’s weather app calls some third party weather API and gives you daily weather updates.
REST stands for Representational State Transfer. REST has a different set of functions like GET, PUT, DELETE, etc. that is used by clients to communicate with the server for exchanging data.
The client makes requests, and the server responds with resources. Here client and server are two independent entities.
Each client’s request to the server must contain all the information needed to process the request. Any state of the client's session is not stored in the server side.
Responses must define themselves as cacheable or non-cacheable to prevent clients from reusing stale data.
The architecture is to allow an application to be composed of hierarchical layers by constraining component behavior such that each component has no idea about the immediate layer with which they are interacting.
This simplifies and decouples the REST architecture and each can evolve independently.
This includes:
a. Identification of resources:
URIs (Uniform Resource Identifiers) used to identify the requests.
b. Manipulation of resources through representations:
When a client processes a representation of a resource, including enough information to modify or delete the resource as metadata,
c. Self-descriptive messages:
The message is processed using the information included in each message.
Allow future changes without breaking existing clients. The common approach is to include the version in the URL.
Ex:
/api/v1/users - GOOD
/api/users - OK, NOT BAD
a. GET: for retrieving data.
b. POST for adding new resources.
c. PUT for updating existing resources
d. PATCH for partially update existing resources
e. DELETE for deleting the resources.
Names should be clear and descriptive and avoid using verbs in the endpoints. instead, use nouns that represent the resource.
Ex:
Get users informations
[GET] /users - GOOD
[GET] /get/users - BAD
Get user information
[GET} /users/123 - GOOD
[GET] /get/users/123 - BAD
Create user
[POST] /users [With request body] - GOOD
[POST] /create/user [With request body] - BAD
[GET] /new/user - BAD
Each client request must contain all the information that needs to fulfill the request. This helps to simplify the server design and improves scalabillity.
Implementing consistent error handling using standard HTTP status codes and also provide meaningful error messages in the response body without exposing server information.
HTTP status codes has following groups
100-199 = Informational responses
100 for Continue
200-299 = Successful responses
200 for Success
204 No content
300-399 = Redirection messages
300 for multiple choices
301 for moved premanantly
400-499 = Client error responses
400 for Bad requests
401 for unauthorized
404 for Not found
500-599 = Server error responses
500 for internal server error
By implementing Authentication and authorization you can secure your APIs. for this you can use methods such as JSW(JSON web tokens) for stateless authentication and ensure sensitive data is protected.
Providing comprehensive documentation for the APIs makes it easier for developers to understand how the API works. You can use Tools like Swagger.
To protect your server from being overwhelmed by too many requests and ensure fair usage of the API.