In a single HTTP Request/Response transaction there are a total of six places that information can be stored. If you are designing a web service, which of the six you choose depends on the context, i.e. where and how your service is going to be used.

For an illustrative example, consider this elided request/response from the draft EchoAPI RFC. Here is the request:

POST /reilly HTTP/1.1
Content-Type: application/not-echo+xml

<?xml version="1.0" encoding='iso-8859-1'?>
<entry>
<title>My First Entry</title>
<subtitle>In which a newbie learns to blog...</subtitle>
<summary>A very boring entry...</summary>
...
</entry>

And the response is:

HTTP/1.1 201 Created
Content-Type: application/not-echo+xml

<?xml version="1.0" encoding='iso-8859-1'?>
<entry>
<title>My First Entry</title>
<subtitle>In which a newbie learns to blog...</subtitle>
<summary>A very boring entry...</summary>

<id>urn:example.org:reilly:1</id>
...
</entry>

The six different locations to store information are:

1. The request URI. Okay, this is the first line of the request and also contains the method, like GET or PUT, I'm lumping them together to simplify things.
2. The request headers, in RFC 822 format, you might remember that I've talked about RFC 822 Headers before.
3. The request message body.
4. The response status code. This is the first line of the
5. The response headers, again in RFC 822 format.
6. The response message body.

That's a lot of choices. When designing a service it's not always clear where some components of a message should be placed. For example, if you are attaching to a service that requires authentication, do you encode the authentication information into the requesting URI, do you use one of the HTTP authentication mechanisms which puts the authentication in the request headers, or do you put a name and password into the message body being sent? You could also send custom HTTP headers with authentication information. None of the choices are inherently better than another. All of the choices have their pros and cons, and each are appropriate depending on the context.

For example, Bulu, the code that runs this site, encodes the authentication information in the URI when doing Editable Comments. It's the least secure method, but the given the context, editing comments on a weblog, it's adequate. On the other hand, Bulu uses one of the HTTP Authentication mechanisms when creating or editing entries. That action requires more security than editing comments.

So where should you store your information? Beats me, but just keep in mind that as you design your service that you have six places to choose from.