HTTP is a simple request-response client-server protocol. This protocol has various methods, including:
- HEAD
- GET
- POST
You’re probably already familiar with these methods if you have ever coded an HTML form or an AJAX call.
In practice, there have been some de facto standards established for Web apps that browsers, Web servers, and programmers follow. For example, the famous 404 page, which is typically sent as the response when a page on the server does not exist. Well, this is wrong! As the HTTP specification states:
404 Not Found
The server has not found anything matching the Request-URI. No indication is given of whether the condition is temporary or permanent. The 410 (Gone) status code SHOULD be used if the server knows, through some internally configurable mechanism, that an old resource is permanently unavailable and has no forwarding address. This status code is commonly used when the server does not wish to reveal exactly why the request has been refused, or when no other response is applicable.
What this means is that a 404 is only meant for situations when we don’t want to be particularly helpful to the client. For example, if we have changed the URL temporally:
307 Temporary Redirect (since HTTP/1.1)
The requested resource resides temporarily under a different URI. Since the redirection MAY be altered on occasion, the clientSHOULD continue to use the Request-URI for future requests. This response is only cacheable if indicated by a Cache-Control or Expires header field.
The temporary URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI , since many pre-HTTP/1.1 user agents do not understand the 307 status. Therefore, the note SHOULD contain the information necessary for a user to repeat the original request on the new URI.
If the 307 status code is received in response to a request other thanGET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.
If we have permanently changed the URL for this resource, we could use:
301 Moved Permanently
The requested resource has been assigned a new permanent URIand any future references to this resource SHOULD use one of the returned URIs. Clients with link editing capabilities ought to automatically re-link references to the Request-URI to one or more of the new references returned by the server, where possible. This response is cacheable unless indicated otherwise.
The new permanent URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI.
If the 301 status code is received in response to a request other thanGET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.
And if we have simply removed the resource:
410 Gone
The requested resource is no longer available at the server and no forwarding address is known. This condition is expected to be considered permanent. Clients with link editing capabilities SHOULDdelete references to the Request-URI after user approval. If the server does not know, or has no facility to determine whether the condition is permanent, the status code 404 (Not Found) SHOULDbe used instead. This response is cacheable unless indicated otherwise.
The 410 response is primarily intended to assist the task of web maintenance by notifying the recipient that the resource is intentionally unavailable and that the server owners desire that remote links to that resource be removed. Such an event is common for limited-time promotional services, and for resources belonging to individuals no longer working at the server’s site. It is not necessary to mark all permanently unavailable resources as “gone” or to keep the mark for any length of time — that is left to the discretion of the server owner.
As you can see, the different codes will help both the user and the server to drive people to the correct places. Only when a resource / service has never been issued with that URL should the server respond with the 404 error.
The same thing happens when we construct a form to send an action to a server. For example, consider the following:
1. Form has a POST method for the “/friend-request” URL.
2. The server receives the request on the proper URI, and executes the script “friend-request.”
3. The server replies back with a new HTML page and an HTTPstatus 200, which tells us that the “friend-request” script ran successfully.
Now we need to deal with the logic where we set that if a user sends multiple requests that are the same, we ignore the first ones, or we send a 200 http status page with content that explains that that relationship is done. What this means is that we force this URI to have an *idempotent* behavior when the actual definition of thePOST HTTP method says the following:
POST
The POST method is used to request that the origin server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI in the Request-Line. POST is designed to allow a uniform method to cover the following functions:
- Annotation of existing resources
- Posting a message to a bulletin board, newsgroup, mailing list or similar group of articles
- Providing a block of data, such as result of submitting a form, to a data-handling process
- Extending a database through an append operation
If we look closer to the definition of the PUT method, we will see this definition:
PUT
The PUT method requests that the enclosed entity be stored under the supplied Request-URI. If the Request-URI refers to an already existing resource, the enclosed entity SHOULD be considered as a modified version of the one residing on the origin server. If the Request-URI does not point to an existing resource, and that URI is capable of being defined as a new resource by the requesting user agent, the origin server can create the resource with that URI. If a new resource is created, the origin server MUST inform the user agent via the 201 (Created) response.
If an existing resource is modified, either the 200 (OK) or 204 (No Content) response codes SHOULD be sent to indicate successful completion of the request. If the resource could not be created or modified with the Request-URI, an appropriate error responseSHOULD be given that reflects the nature of the problem. The recipient of the entity MUST NOT ignore any Content-* (e.g. Content-Range) headers that it does not understand or implement and MUSTreturn a 501 (Not Implemented) response in such cases.
If the request passes through a cache and the Request-URI identifies one or more currently cached entities, those entries SHOULD be treated as stale. Responses to this method are not cacheable.
The fundamental difference between the POST and PUT requests is reflected in the different meaning of the Request-URI. The URI in aPOST request identifies the resource that will handle the enclosed entity. That resource might be a data-accepting process, a gateway to some other protocol, or a separate entity that accepts annotations. In contrast, the URI in a PUT request identifies the entity enclosed with the request — the user agent knows what URI is intended and the server MUST NOT attempt to apply the request to some other resource. If the server desires that the request be applied to a different URI, it MUST send a 301 (Moved Permanently) response. The user agent MAY then make its own decision regarding whether or not to redirect the request.
That makes this method idempotent, just what we need in this case! This means that if we are creating a new instance of a relationship, why are we using processor cycles in the layers that do not have to use them? Meanwhile, we have an already designed and implemented protocol, both in the client and the server, to allow this idempotent action to go. Well, the answer is “we don’t know yet howHTTP really works!” Some might think that the POST method is valid for every action due to the definition, but if you want to explore the best of your resources, you might want to see the HTTP definition further.
Another example of where HTTP can help is with its support for caching.
Imagine a URL that identifies your friend list. A GET to this URLreturns a list of your friends and a 200 status code. Without caching, every time a client asks for this resource, a server needs to generate the list of friends, even if the list hasn’t changed. Since the list changes relatively infrequently, this is a great place to use caching. Uh oh! Here comes another request! According to the specifications, here’s the HTTP code we might want to use:
304 Not Modified
If the client has performed a conditional GET request and access is allowed, but the document has not been modified, the serverSHOULD respond with this status code. The 304 response MUSTNOT contain a message-body, and thus is always terminated by the first empty line after the header fields.
This only sends back headers, avoids regenerating the list of friends, and reduces the amount of bandwidth required for the response. Cool, huh?
There are a lot more examples that can enhance our application online without needing to change much on the server and the client.HTTP protocol has so many potential uses that we haven’t even started to standardize in the web programmers life.
____________________
Finally, another good example of taking full advantage of HTTP is with file uploads. Many sites have a way to upload images or other files. Usually, this is implemented by having the server receive the file and then determine whether the file is acceptable (not too large and formatted using a supported media type), possibly rejecting the file by sending an error page and an HTTP 200 status. Here, again, we aren’t really making good use of the protocol. To begin with, there are status codes for this exact scenario.
If the file that the user is trying to upload is too long:
413 Request Entity Too Large
The server is refusing to process a request because the request entity is larger than the server is willing or able to process. The server MAY close the connection to prevent the client from continuing the request.
If the condition is temporary, the server SHOULD include a Retry- After header field to indicate that it is temporary and after what time the client MAY try again.
If the file that the user has uploaded is not accepted by the server:
415 Unsupported Media Type
The server is refusing to service the request because the entity of the request is in a format not supported by the requested resource for the requested method.
In combination with the OPTIONS method, this also allows us to check whether a file is going to be acceptable before we send it, which can potentially save a lot of wasted bandwidth sending unacceptable files.
If you would like to better understand the HTTP protocol and its further implementations that can help your site, check out these links:
Recent Comments