HTTP (Hyper Text Transfer Protocol) enables the communication between client and server. It works as a request response protocol. An HTTP client opens a connection and sends a request message
to an HTTP server; the server then returns a response message,
usually containing the resource that was requested. After delivering
the response, the server closes the connection.
Structure of HTTP transactions
Both response and request messages consist of :
- An initial line
- Zero or more header lines
- Blank line
- An optional message body
Initial request line
A request line has three sections, separated by space : a method name, the local path of the requested resource, and the version of the HTTP being used.
*The HTTP version always takes the form "HTTP/x.x", uppercase.
Initial response line
The initial line is different for the response than for the request. But it also has three parts separated by space : the HTTP version, a response status code, phase that describes the status
eg: HTTP/1.1 405 Method Not Allowed
The status code is a three-digit integer, and the first digit identifies
the general category of response:
- 1xx indicates an informational message only
- 2xx indicates success of some kind
- 3xx redirects the client to another URL
- 4xx indicates an error on the client's part
- 5xx indicates an error on the server's part
Header lines provide information about the request or response, or about the object sent in the message body.
The Message Body
An HTTP message may have a body of data sent after the header lines. In a response, this is where the requested resource is returned to the client (the most common use of the message body), or perhaps explanatory text if there's an error. In a request, this is where user-entered data or uploaded files are sent to the server.
If an HTTP message includes a body, there are usually header lines in the message that describe the body. In particular,
- The Content-Type: header gives the MIME-type of the data in the body, such as text/html or image/gif.
- The Content-length: header gives the number of bytes in the body.
Request message :
GET / HTTP/1.1
User-Agent: curl/7.35.0
Host: www.google.lk
Accept: */*
[blank line here]
Response message
HTTP/1.1 405 Method Not Allowed
Allow: GET, HEAD, OPTIONS, TRACE
Content-Type: text/html
Server: Microsoft-IIS/7.0
X-Powered-By: ASP.NET
Date: Thu, 06 Aug 2015 09:01:38 GMT
Content-Length: 1293
Allow: GET, HEAD, OPTIONS, TRACE
Content-Type: text/html
Server: Microsoft-IIS/7.0
X-Powered-By: ASP.NET
Date: Thu, 06 Aug 2015 09:01:38 GMT
Content-Length: 1293
<html>
<body>
<h1>Some text </h1>
(more file contents)
.
.
.
</body>
</html>
HTTP Methods
GET
The GET method
means retrieve whatever information (in the form of an entity) is
identified by the Request-URI. Requests using GET should only
retrieve data and should have no other effect on the data
example of HTTP GET
request :
GET /home.html
HTTP/1.1
User-Agent:
Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host:
www.java67.blogspot.com
Accept-Language:
en-us
Accept-Encoding:
gzip, deflate
Connection:
Keep-Alive
A client would send
Connection:
Keep-Alive
to indicate that it
desires to keep the connection open for multiple requests. The server
may then respond with a message containing
Connection:
Keep-Alive
to indicate that the
connection will be kept open for the next request. The Connection
header field with a keep-alive keyword must be sent on all requests
and responses that wish to continue the persistence. The client sends
requests as normal and the server responds as normal, except that all
messages containing an entity body must have a length that can be
determined without closing the connection (i.e., each message
containg an entity body must have a valid Content-Length, be a
multipart media type, or be encoded using the "chunked"
transfer coding).
The Keep-Alive
header field may be used to include diagnostic
information and other optional parameters. For example, the server
may responds with
Connection:
Keep-Alive
Keep-Alive:
timeout=10, max=5
to indicate that the
server has selected (perhaps dynamically) a maximum of 5 requests,
but will timeout if the next request is not received within 10
seconds. However, that this additional information is optional
and the Keep-Alive header field does not need to be present. If it is
present, the semantics of the Connection header field prevents it
from being accidentally forwarded to downstream connections.
The persistent
connection ends when either side closes the connection or after the
receipt of a response which lacks the "keep-alive" keyword.
The server may close the connection immediately after responding to a
request without a "keep-alive" keyword. A client can tell
if the connection will be closed by looking for a "keep-alive"
in the response.
POST
POST submits data to be processed (e.g., from an HTML form) to the
identified resource. The data is included in the body of the request.
This may result in the creation of a new resource or the updates of
existing resources or both.
POST / HTTP/1.1
User-Agent: curl/7.35.0
Host: www.abc.lk
Accept: */*
Content-Length: 10
Content-Type: application/x-www-form-urlencoded
Host: www.abc.lk
Accept: */*
Content-Length: 10
Content-Type: application/x-www-form-urlencoded
Difference between GET and POST Method
- GET is a safe method (idempotent) where POST is non-idempotent method. A HTTP method is said to be idempotent if it returns the same result every time. HTTP methods GET, PUT, DELETE, HEAD, and OPTIONS are idempotent method and we should implement our application to make sure these methods always return same result. HTTP method POST is non-idempotent method and we should use post method when implementing something that changes with every request. For example, to access an HTML page or image, we should use GET because it will always return the same object but if we have to save customer information to database, we should use POST method. Idempotent methods are also known as safe methods and we don’t care about the repetitive request from the client for safe methods.
- We can only send limited data with GET method and it’s sent in the header request URL whereas we can send large amount of data with POST because it’s part of the request body.
- GET method is not secure because data is exposed in the URL and we can easily bookmark it and send similar request again, POST is secure because data is sent in request body and we can’t bookmark it. By the way this would not be enough if security is concern because HTTP request can be intercepted en-route. Better use HTTPS or SSL encryption to make HTTP communication secure.
- GET is the default HTTP method whereas we need to specify method as POST to send request with POST method.
The PUT method requests that the enclosed entity be stored under the
supplied Request-URI.
PUT / HTTP/1.1
User-Agent: curl/7.35.0
Host: www.abc.lk
Accept:application/json
Content-Length: 11
Content-Type: application/x-www-form-urlencoded
User-Agent: curl/7.35.0
Host: www.abc.lk
Accept:application/json
Content-Length: 11
Content-Type: application/x-www-form-urlencoded
PUT Vs POST
The HTTP methods POST and PUT aren't the HTTP equivalent of the create and update. They both serve a different purpose. It's
quite possible, valid and even preferred in some occasions, to use
POST to create resources, or use PUT to update resources.
Use PUT when you can update a resource completely through a specific
resource. For instance, if you know that an article resides at
http://example.org/article/1234, you can PUT a new resource
representation of this article directly through a PUT on this URL.
If you do not know the actual resource location, for instance, when
you add a new article, but do not have any idea where to store it,
you can POST it to an URL, and let the server decide the actual URL
OPTIONS
This method allows the client to determine the options and/or
requirements associated with a resource, or the capabilities of a
server. As an authorized user on an API, if you were to request OPTIONS
/users/me, you should receive something like...
Request
OPTIONS / HTTP/1.1
User-Agent: curl/7.35.0
Host: www.abc.lk
Accept:application/json
Host: www.abc.lk
Accept:application/json
Response
HTTP/1.1 200 OK
DELETE
HTTP/1.1 200 OK
Allow: OPTIONS, TRACE, GET, HEAD, POST
HEAD
you can ask the remote server only for the header
DELETE
The DELETE method requests that the origin server delete the resource
identified by the Request-URI. 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. However, the server SHOULD NOT indicate success unless,
at the time the response is given, it intends to delete the resource
or move it to an inaccessible location.
CONNECT
This method could allow a client to use the web server as a proxy.
TRACE
The HTTP trace request (containing request line, headers, post data),
sent to a trace supporting web server, will respond to the client
with the information contained in the request. Trace provides any
easy way to tell what an HTTP client is sending and what the server
is receiving.
No comments:
Post a Comment