Working With HTTP Verbs

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
100Continue
101Switching Protocols
102Processing
200OK
201Created
202Accepted
203Non-Authoritative Information
204No Content
205Reset Content
206Partial Content
207Multi-Status
208Already Reported
226IM Used
300Multiple Choices
301Moved Permanently
302Found
303See Other
301Moved Permanently
302Found
303See Other
304Not Modified
305Use Proxy
306Switch Proxy
307Temporary Redirect
308Permanent Redirect
400Bad Request
401Unauthorized
402Payment 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

Up Next
    Ebook Download
    View all
    Learn
    View all