Probably during the course of learning about web programming you are familiar with terms like Back-end and Front-end. So have you ever wondered in the same project if BE – FE would use two separate languages, what would it be like and what made the link between these two aspects? To solve this problem, the introduction of APIs (Application Programming Interface) – the application programming interface is essential. In order to use APIs effectively, this article will introduce you to APIs’ protocols and HTTP response statuses.
HTTP protocol
The REST API allows you to develop any type of web application that has all possible CRUD activities (create, retrieve, update, delete). REST guidelines suggest using a specific HTTP method on a specific type of call made to the server (although it might technically violate this rule, but it is highly discouraged). .
REST APIs allow you to develop any type of application including all CRUD actions (create, access, update, delete). REST standard principles encourage you to use a specific HTTP method for each specific type of action (using other methods is technically possible, although still possible but not recommended).
To use the method effectively, please review the following content and choose for yourself the appropriate way to use:
- HTTP GET
- HTTP POST
- HTTP PUT
- HTTP DELETE
- HTTP PATCH
- summary
HTTP GET
HTTP GET is used to retrieve objects – and does not modify the information in any way. GET method, when used and not changing the state of the object, is considered a safe method. In addition, GET APIs must be idempotent, meaning that making many of the same requests must produce the same result until another API (POST or PUT) changes the state of the object on the server.
If the request is made on an object that is being processed, the object created during processing will be the object returned in the response and not the original object from the server, unless that object is output. request’s default.
For any given HTTP GET API, if the object is found on the server, it must return an HTTP response status 200 (OK) – along with the body response, usually XML or JSON content (due to dependency). with web writing platform).
In case the object is NOT found on the server, it returns an HTTP response status 404 (NOT FOUND). Similarly, if the params passed in the GET request are incorrect, the server will return an HTTP response status 400 (BAD REQUEST).
Some examples of request URIs
- HTTP GET {{host}} / careers
- HTTP GET {{host}} / careers / 1
HTTP POST
Use the API POST to create a new object in the database, for example, create a file in a specific directory or a row in a database table. Seriously about REST, the POST methods are used to create new objects into the database.
Ideally, if the data is created on the server, the server will return an HTTP response status 201 (CREATED) and contain an object describing the state of the request and a reference to the new object and its location.
Sometimes, actions taken by the POST method may not result in an object that can be identified by a URI. In these cases the server will return an HTTP response status 200 (OK) or 204 (NO CONTENT).
The responses for this method are not cached unless the response includes the Cache-Control or Expires fields in the appropriate header.
Note: POST is neither secure nor idempotent, calling two identical POST requests will result in two different data containing the same information (except for the Data ID).
Example of request URIs
- HTTP POST {{host}} / careers
HTTP PUT
Use the PUT API primarily to update existing objects (if data does not exist, then the API can decide whether to create new objects or not). If the new object has been created by API PUT, the server MUST notify the user via HTTP response status 201 (CREATED) and if the existing object is modified, then the HTTP response status 200 (OK) or 204 (NO CONTENT) ) SHOULD be sent to indicate completion of the request.
Differences between API POST and PUT can be observed in request URIs. POST requests are made on the database, while PUT requests are made on an individual object.
Some examples of request URIs
- HTTP PUT {{host}} / careers / 123
- HTTP PUT {{host}} / users / 22 / careers / 1
HTTP DELETE
The name says it all, the DELETE API is used to delete the object (defined by the request URI).
HTTP response status 200 (OK) if the response includes an entity that describes the status, 202 (ACCEPTED) if the action has been queued or 204 (NO CONTENT) if the action was taken but the response did not include an object.
The DELETE operation is idempotent. If you DELETE an object, it will be deleted from the database. Continuing to call the DELETE API on that data will not change the result – however, calling DELETE on the second data will return a 404 (NOT FOUND) because it has been deleted. Depending on the point of view, some might argue that it makes the non-idempotent DELETE method, which is still an issue that needs more discussion.
If the request passes the cache and the request URI identifies one or more objects currently cached, those items SHOULD be considered “stale”. Feedback for this method is “not cacheable”.
Example request URIs
- HTTP PUT {{host}} / careers / 1
HTTP PATCH
The HTTP PATCH request is used to make partial updates to the selected object. So, now we have 2 requests that update the data: PUT and PATCH, depending on the situation that we will use them properly: PATCH will be used when we want to update a part of the object and PUT is to replace the whole object.
However, the use of PATCH is quite limited:
- Many software applications no longer support the PATCH method.
- The request payload of the PATCH method is not as obvious as the PUT:
For example:
With the GET request
HTTP GET /careers/1We will have a response data of:
123456{"id": 1,"carreer": "devlopment","company_email": " <a class="__cf_email__" href="/cdn-cgi/l/email-protection">[email protected]</a> "}Request to update company_email will take the form
HTTP PATCH /careers/112345678[{"op": "replace","path": "/company_email","value": " <a class="__cf_email__" href="/cdn-cgi/l/email-protection">[email protected]</a> "}]
summary
| HTTP protocol | CRUD | Database | Specific audiences (careers / 1) |
|---|---|---|---|
| POST | Create | 201 (Created), Create a new object in the database. | Avoid using POST on a specific object. |
| GET | Read / Retrieve | 200 (OK), list of careers. Use with sorting, filtering and pagination. | 200 (OK), for getting information about a career. 404 (Not Found), if ID not found or not available. |
| PUT | Update / Replace | 405 (Method not allowed), only when updating the entire database. | 200 (OK) or 204 (No Content). 404 (Not Found), if ID not found or not available. |
| PATCH | Partially updated / Modified | 405 (Method not allowed), when you want to modify a part of the database. | 200 (OK) or 204 (No Content). 404 (Not Found), if ID not found or not available. |
| DELETE | Delete | 405 (Method not allowed), used when you want to delete the database – comes with a warning. | 200 (OK). 404 (Not Found), if ID not found or not available. |
References:
[3] https://www.freecodecamp.org/news/what-is-an-api-in-english-please-b880a3214a82/