Accessing Devices Using a Web Service - HTTP Requests and Responses

(Page 2 of 5 )

HTTP Requests

An HTTP based client application, e.g. a Web browser, establishes a TCP/IP socket connection with an HTTP server and then carries on a request – response conversation.  A typical HTTP request looks like:

GET /listener.htm HTTP/1.1<cr><lf>
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-powerpoint, application/vnd.ms<cr><lf>
Accept-Language: en-us<cr><lf>
Accept-Encoding: gzip, deflate<cr><lf>
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0b; Windows NT 5.0; .NET CLR 1.0.2914)<cr><lf>
Host: the4<cr><lf>
Connection: Keep-Alive<cr><lf>
<cr><lf>

The key things to note are:

1. An HTTP request is just a series of text lines (i.e. displayable text terminated with a carriage return and line feed). An empty line terminates the request.
   
   
2. It provides a wealth of information, most of which we can ignore.
   
   
3. What is important for us is the first line. This includes three key pieces of information. The action requested, the item associated with this request and the version of HTTP used.

The current version of HTTP, 1.1, supports a number of different actions, POST, PUT, COPY etc. but the only one we need for providing information is GET.  A side effect of only supporting GET is that the actions that are prone to be used by hackers to break in will not be supported.

HTTP Responses

An HTTP response has one or two parts.  The response header provides the status information necessary for the client to make use of the response.  If the response includes the movement of data to the client then the second part is the data stream.  We will use three types of responses, a generic error response and two different data response.  The error response is a one part (i.e. header only) response and it is:

HTTP/1.1 400 Bad Request<cr><lf>
Content-length: 0<cr><lf>
<cr><lf>

The key things to note in the error response header are:

1. A response header is just a series of text lines.  An empty line terminates the header.
   
   
2. The first line in the header provides two basic pieces of information, the HTTP version used (which should match that in the request) and the status of the request.
   
   
3. The last line tells the client how big the data stream section will be.  Our error response will include no data section.

There are dozens of possible status responses, each composed of a number and a matching text string.  For out simple service we only need two, 400 Bad Request and 200 OK.  The OK response header is used in the two different data responses we will support.  The first of these is our XML response header.  This is:

HTTP/1.1 200 OK<cr><lf>
MIME-version: 1.0<cr><lf>
Content-type: text/xml<cr><lf>
Connection: keep-alive<cr><lf>
Content-length: 100<cr><lf>
<cr><lf>

This header includes a little more information then the error response header.  The key things to note are:

1. The overall composition of a response header has not changed.
   
   
2. We have included two additional lines which define the nature of the data stream we will be providing:
   
   (a) A line that defines the MIME (Multipurpose Internet Mail Extensions) standard version that is being used.
   
   (b) A line that defines the content type using the indicated MIME standard, in this case XML.
   
   
3. We add the “keep-alive” line so the client will hopefully not drop the socket immediately after each request – response cycle.
   
   
4. The last line must contain the actual byte count in the following data stream.

The second data response will allow us to return an HTML page.  This is:

HTTP/1.1 200 OK<cr><lf>
MIME-version: 1.0<cr><lf>
Content-type: text/html<cr><lf>
Connection: keep-alive<cr><lf>
Content-length: 100<cr><lf>
<cr><lf>

The only thing new here is the content type.  In general we do not need to support an HTML response.  One of the key advantages to providing an XML response is that we are only providing data; we are not specifying how the data should be presented to the user.  This keeps what we have to produce relatively small and easy.  Picking up this data and placing it into a display application is not difficult but it does require some knowledge on the part of the users.  Most of this can be provided in a couple of simple tables but it is always good to provide a simple example.  Along those lines a single HTML page that includes VB or Java script can provide a living example of how to access and use the data provided.  Then it is up to the user organization to build what ever interfaces it needs.

The second part of the data responses is nothing more then the data stream that makes up the response, i.e. we are sending the XML document or HTML page.  The only requirement is that the content type and byte count of this data stream be the same as the information provided in the response header.

Next: XML >>
 

More Web Services Articles
More By Terry Ess

Comments On: Accessing Devices Using a Web Service

>>> Be the FIRST to comment on this article!