Basic CRUD Operations

CRUD Operations
CRUD is an acronym for Create, Read, Update, and Delete. These are the four basic functions that can be performed with most traditional database systems and they are the backbone for interacting with any database.

Pic collected

HTML Verb: POST , CRUD: Create -
The POST function often uses the new resource "create". In particular, it is used to create subordinate resources. That is, no one else is subject to such parental assets. In other words, when creating a new resource, POST the parent and the service takes care of adding new resources to the parent, assigning an ID (new resource URI), etc.
If created successfully, return HTTP status 201, 201 Return a location header with a link to the newly created resource with HTTP status.
Posts are not secure or indomitable. Therefore it is recommended to request non-indomitable resources. Requesting two identical POSTs will probably result in two resources containing the same information.

/api/service /*{create a service if id not exists ,update otherwise}*/

HTML Verb: GET, CRUD: Read-
The HTTP GET method is used to "read" or retrieve an asset presentation. In the "happy" or non-error path, GET provides a presentation in XML or JSON and an HTTP response code of 200 (OK). In case of an error, it often returns a 404 (not found) or 400 (bad request).
According to the design of the HTTP specification, GET (including HEAD) requests are used to read data only and do not change it. Therefore, when used in this way, they are considered safe. That is, they can be called without the risk of data alteration or corruption. Calling it once has the same effect as calling 10 times, or not at all. Additionally, GET (and HEAD) is idempotent, meaning that multiple identical requests yield the same results as a single request.
Do not publish unsafe activities through GET — it should never change any resources on the server.

/api/service /*{returns a single page of service}*/
/api/service/{id} /*{returns a single service as defined by the id provided}*/

HTML Verb: PUT, CRUD: Update-
PUT is often used for "update" capability, PUT-in a familiar resource URI containing a newly-updated representation of the original resource with the request body.
However, PUT can also be used to create a resource where the resource ID is chosen by the client instead of the server. In other words, if the PUT is in a URI that contains the value of a non-existent resource ID. Again, there is a resource presentation in the request section. Many find it complicated and confusing. As a result, this method of creation should be used sparingly, if at all.
Alternatively, use POST to create a new resource and provide the client-defined ID in the body representation - in a URI that does not include the resource ID.
Upon successful update, return 200 from PUT or 204 if no content is returned to the body. When using PUT to create, return HTTP status 201 on successful creation. A body of feedback is optional and uses one more bandwidth. There is no need to return a link with a location title in case of creation as the client has already set the resource ID.
PUT is not a secure operation, it modifies or creates the status on the server, but it is invincible. In other words, if you create or update a resource using PUT and then make the same call again, the resource is still there and still in the same condition as it did with the first call.
For example, if a PUT call on an asset increases one counter of the asset, the call is no longer invincible. Sometimes this happens and it may be enough to document that the call is not indomitable. However, it is advisable to keep PUT requests in abeyance. It is strongly recommended to use POST for non-refractory requests.
/api/service /*{create a service if id not exists , update otherwise}*/

HTML Verb: DELETE, CRUD: Delete-
DELETE is quite easy to understand. It is used to "delete" a resource identified by a URI.
If successfully deleted, return HTTP status 200 (OK) with a response body, perhaps a presentation of the deleted item (often demanding too much bandwidth), or a wrapping response (see return value below). Either that or return HTTP status 204 (no content) without a response body. In other words, a 204 status without any body, or JSEND-style response and HTTP status 200 is the recommended response.
HTTP-Spec-Wise, Delete operations are indomitable. When you delete an asset, it is removed. Repeated DELETE calls to that resource have the same consequences: the resource is gone. Calling DELETE means reducing a counter (within resources), the DELETE call is no longer invincible. As mentioned earlier, usage statistics and measurements may be updated while still considering the service incomplete unless any resource data is changed. It is recommended to use POST for non-exhaustive resource requests.
However, there is a warning about DELETE disability. A second call to the resource DELETE will often return a 404 (not found) since it has already been removed and is therefore no longer found. This, in some respects, makes DELETE operations more incapacitated, however, the end state of the asset remains the same. A 404 return is acceptable and communicates the status of the call correctly.
/api/service/{id} /*{delete a single service as defined by the id provided}*/