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


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 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 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


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
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