HTTP Verbs
HTTP verbs tell the server what to do with the data identified by the URL. The HTTP method is supplied in the request line and specifies the operation that the client has requested. If you're going to follow the REST architecture and the HTTP protocol, you must choose from the verbs available in that protocol, the primary or most-commonly-used HTTP verbs are POST, GET, PUT, and DELETE.
These correspond to create, read, update, and delete (or CRUD) operations.
Using HTTP verbs
GET
This method is used to retrieve a representation of a resource. A GET request is considered safe because as HTTP specifies, these requests are used only to read data and not change it.
So in short there are no side effects and GET requests can be re-issued without worrying about the consequences.
The disadvantage of GET requests is that they can only supply data in the form of parameters encoded in the URI or as cookies in the cookie request header.
For example: Displaying your registered account details on any website has no effect on the account. If you are using Internet Explorer you can refresh a page and the page will show information that resulted from a GET, without displaying any kind of warning. We have also other HTTP components like PROXIES that automatically retry GET requests if they encounter a temporary network connection problem.
Tasks that you can do with GET requests are:
- You can cache the requests
- It can remain in the browser history
- You can bookmark the requests
- You can apply length restrictions with GET requests
- It is used only to retrieve data
POST
POST is used when the processing you wish to do on the server should be repeated or when creating a new resource or for a POST to the parent when the service associates the new resource with the parent or for assigning an ID, etcetera. It is used to create new resources. For some resources, it may be used to alter the internal state. For others, its behavior may be that of a remote procedure call. If you try to refresh a page while using a POST request, then you will get an error like page can't be refreshed. Why? Because the request cannot be repeated without explicit approval by the user.
Example: The best example of a POST request I must say is when the user submits a change and then uses a 302 redirection (Code redirection details you will find later on this article) to change to a GET that displays the result of the action as the new updated value.
Some important points about POST requests:
- Data will be re-submitted
- It cannot be bookmarked
- It cannot be cached
- Parameters are not saved in browser history
- No restrictions. Binary data is also allowed
- Data is not displayed in the URL
PUT
PUT is used to create a resource, not in a general case but when the resource ID is chosen by the client instead of by the server, then only PUT is used. Simply PUT updates data in the repository, replacing any existing data with the supplied data.
For example: Suppose we wanted to change the image that we have something already on the server, So, we just upload a new one using the PUT verb.
Some good points of PUT requests are:
- It completes as possible
- It's as seamless as possible
- Easy to use via HTML
- It should integrate well with servers that already support PUT
DELETE
A DELETE request is as simple as its name implies; it just deletes, it is used to delete a resource identified by a URI and on successful deletion, it returns HTTP status 200 (OK) along with a response body. The importent and unique thing about a DELETE request is that the client cannot be guaranteed that the operation has been carried out, even if the status code returned from the origin server indicates that the action has been completed successfully.
Some HTTP infrastructures do not support the DELETE method. In such cases, the request should be submitted as a POST with an additional X-HTTP-Method-Override header set to DELETE.
Example DELETE request: DELETE /data/myDataApp/myorder/-/takenOrdernumber('00777')
HTTP status codes listed in Wikipedia:
Code Number | Status |
100 | Continue |
101 | Switching Protocols |
102 | Processing |
200 | OK |
201 | Created |
202 | Accepted |
203 | Non-Authoritative Information |
204 | No Content |
205 | Reset Content |
206 | Partial Content |
207 | Multi-Status |
208 | Already Reported |
226 | IM Used |
300 | Multiple Choices |
301 | Moved Permanently |
302 | Found |
303 | See Other |
301 | Moved Permanently |
302 | Found |
303 | See Other |
304 | Not Modified |
305 | Use Proxy |
306 | Switch Proxy |
307 | Temporary Redirect |
308 | Permanent Redirect |
400 | Bad Request |
401 | Unauthorized |
402 | Payment Required |
403 | Forbidden |
404 | Not Found |
405 | Method Not Allowed |
406 | Not Acceptable |
407 | Proxy Authentication Required |
408 | Request Timeout |
409 | Conflict |
410 | Gone |
411 | Length Required |
412 | Precondition Failed |
413 | Request Entity Too Large |
414 | Request-URI Too Long |
415 | Unsupported Media Type |
416 | Requested Range Not Satisfiable |
417 | Expectation Failed |
418 | I'm a teapot |
420 | Enhance Your Calm |
422 | Unprocessable Entity |
423 | Locked |
424 | Failed Dependency |
424 | Method Failure |
425 | Unordered Collection |
426 | Upgrade Required |
428 | Precondition Required |
429 | Too Many Requests |
431 | Request Header Fields Too Large |
444 | No Response |
449 | Retry With |
450 | Blocked by Windows Parental Controls |
451 | Unavailable For Legal Reasons |
451 | Redirect |
494 | Request Header Too Large |
495 | Cert Error |
496 | No Cert |
497 | HTTP to HTTPS |
499 | Client Closed Request |
500 | Internal Server Error |
501 | Not Implemented |
502 | Bad Gateway |
503 | Service Unavailable |
504 | Gateway Timeout |
505 | HTTP Version Not Supported |
506 | Variant Also Negotiates |
507 | Insufficient Storage |
508 | Loop Detected |
509 | Bandwidth Limit Exceeded |
510 | Not Extended |
511 | Network Authentication Required |
598 | Network read timeout error |
599 | Network connect timeout error |