h1

structured GET requests

October 24, 2006

HTTP has a problem; due to the representation of URLs and the specification of GET requests, it is unwieldy for encoding structured request parameters, long or many parameters, and parameters with certain characters. Take for example, this ideal request object that is consumed and processed by an ecommerce website:

<request>
    <request-document>my shopping cart</request-document>
    <request-parameters>
        <name>Jack Gardener</name>
        <session-id>1234567890</session-id>
        <filters>
            <filter key="item-name" op="regex">.*battery.*</filter>
            <filter key="item-view-date" op="greater">12-12-2006</filter>
        </filters>
        <view-preference>
            <skin>Milky White v1.0</skin>
            <font-metric>px</font-metric>
        </view-preference>
    </request-parameters>
</request>

You can see that this request is inherently a GET request; it fetches a cache-able document with no side effects. Also, the request object is inherently structured and belongs in XML form. Herein lies the problem. The usual approach to this problem is to fit the request parameters into a single line in URL-Escaped form. I think it would also be possible to fit the request XML object in the body of a POST request, but I believe most browsers cannot do this well, at least not with HTML-forms (also, the request is not inherently a POST request, so this would be a bad idea).

SOAP could be used to represent request parameters for websites, but it doesn’t solve the cache problem. Also, it’s a far ways from becoming incorporated into browsers and web-servers; it’s too abstract / transport independent to get widespread adoption. I may be wrong, but when it comes to adoption, I’m a strong believer of evolution (like IP > TCP > HTTP), not intelligent design. Just ask these guys.

Here is an idea: The client POSTs the request object to the server, and the server redirects the client to either (1) a URL that includes a session parameter or (2) a URL that includes a parameter that represents the request object, possibly in compressed and base64 form. In the first case, the server is responsible for remembering the request object, and in the second case, the server doesn’t. Either way, the request is completely cache-able in all levels as long as the browser or client can associate the request object with the redirect URL.

There are several layers of caching that needs to be considered:

  1. browser level caching of the final response document
  2. browser level caching of the final redirect URL based on response object
  3. cloud level caching of the document
  4. server level caching of the final redirect URL based on response object
  5. server level caching of the response document

Caching of levels 1, 3, and 5 come free because the browser/client is redirected to a HTTP GET requests to fetch the document (See how). Level 4 is easily implemented by a servlet or module, or even by a third party webservice (kind of like tinyurl). Level 1, I believe, requires a new browser plugin or implementation. But, at least it’s possible. Image if links were no longer a long cryptic string but a structured XML document with human readable parameter values. There are also many benefits that come with structured requests and the ability to declare name-spaces that I won’t write right now, but I’m thinking along the lines of client/browser and user preferences.

Advertisements

One comment

  1. Thats a good article. Thanks.



Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: