The old days when embedded devices and factory floor machines had only minimal interaction with humans, the on/off button and little else, are gone. Today the ability to access the device from anywhere is expected. This is a significant challenge when we are sweating over every dollar required in hardware. With a little bit of knowledge and a relatively small piece of software, we can provide a Web service for this type of interaction.
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:
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.
It provides a wealth of information, most of which we can ignore.
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:
A response header is just a series of text lines. An empty line terminates the header.
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.
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:
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.
Web Services 
/ 16 
XML Strengths and Weaknesses with DOM, ASP and XSL
