Requests and responses make HTTP work; they are the yin and yang of Client / Server communications.  Last time, I covered some of the most common response codes and what they mean.  Today, I will be covering the different ways in which these communications can be called from the client.GET and POSTGET and POST are the 2 most common request methods.  GET is intended for the retrieval of information while POST is intended for the submission of information as a subordinate of the requested resource.When To Use GETGET should only be used when security is not an issue and all information can be included as part of the URL string.  GET has added the benefit in that it can be used with Cacheable data to reduce network usage.  Most server side environments allow you to include and process information included in the URI of the GET request.  This is generally a bad idea as all information included in the URI is transmitted in a form potentially visible to third parties.  Where security is not an issue that can be a more efficient way of getting information to a server.When To Use POST POST is ideally suited to transmitting dynamic information to the server.  Post supports the following benefits over GET for this purpose.

• Information is not included in public facing URI request.
• Larger quantities of data can be transmitted
• Request data is not cached

Other MethodsThere are several other methods supported by HTTP 1.1 that you may find useful at some point.  Not all of these are readily accessed from within the Browser environment, however.

• HEAD: Identical to GET except only the header and no body is returned
• PUT: Requests that the attached body be stored under the requested URI.  If the resource already exists, it should be overwritten by the new version.
• DELETE: Requests that the resource at the requested URI be deleted.
• TRACE: A Debugging method, it requests that the request (as received by the server) be transmitted back to the client in the entity body.
• CONNECT: A reserved name for future support for dynamically switching to tunnel proxies.

I know what you’re thinking, mobile aps run on cellphones and smartphones, not PC’s. Mobile sites are one of the most important and pervasive aspects of this hybrid web ecosystem. Unlike desktops and laptops, mobile sites can assume that the cellular device they are displayed on will have a persistent and portable net connection. Because of this benefit, mobile sites can be viewed as intermediaries to be used with a user may not have access to a traditional internet connection.

Unfortunately, mobile platforms are and always will be limited devices. There simply is no way to put all of the screen real estate of even the smallest monitor into a device that will fit into someones pocket without resorting to origami voodoo. Higher screen resolutions help the situation, but there are limits to the human visual system and 6pt font is almost as eligible on paper as it is on any digital screen.

Other restrictions abound surrounding the mobile platform. From a user interface perspective it’s still a bit of the wild west and mobile browsers have tended to be flaky, inconsistent and underpowered. Safari, Opera and Minimo make significant strides towards eliminating these issues and providing a much richer platform on which to develop. Many cellphones also provide API’s to enable mobile aps to look consistent with, act like and interface with the underlying device.

The inconsistencies across platforms still make mobile devices a difficult nut to crack in terms of development. As browsers, bandwidth and processing power improves, expect developing for them to increasingly less frustrating and in higher demand from users.

You’re probably already quite familiar with the 404 Status Code for resources that aren’t found.  Knowing the status codes can give you some pretty powerful insight into the server side of your app when things go wrong.All Errors fit into the following categories

•  1XX Informational Codes
• 2XX Success Codes
• 3XX Redirection
• 4XX Client Error
• 5XX Server Error

The Codes in More Depth Informational Codes 1XX Informational Codes are unique in that they return no body and terminate immediately after the headers.  The most common encountered is “100 Continue”.   Continue responses are roughly equivalent to the server saying I haven’t forgotten about you.  They imply that everything is fine but that the server isn’t prepared to issue a response yet.  If the client is still transmitting data, the client should continue to do so.  If the client is done transmitting, it can ignore the response.  The server is required to send a normal response in the future.   Success Codes 2XX The most common code in this category is 200 OK.  This is what you expect to receive in any http transaction.  Some other common codes are:

• 202 Accepted: The Server has accepted the request but hasn’t finished processing.  It should contain a pointer to more information but isn’t required to do so. 
• 204 No Content: The Server has completed the request but there is no need to return a body entity.  There may be new meta-data to transmit.  Clients should not change their document view when this code is received.
• 206 Partial Content: On Get Requests, this means that the originating GET request included a Range header field and only that range is returned.

3XX Redirection CodesRedirection codes communicate that the previous request was insufficient to complete the request and further action needs to be taken by the client to do so.

• 301 Moved Permanently: The resource has been permanently relocated to a different URI.  Any future references should use this new URI.  The Response Body should contain a short note in HTML with a link to the new location.
• 307 Temporary Redirect: The resource is temporarily relocated at a new URI.  Future references should continue to use the original URI.

4XX Client Error  While we’re all familiar with the infamous 404 not found error.  There are several other client errors that can be encountered on a regular basis.

• 400 Bad Request: The HTTP Request is malformed.  The Client should not repeat the request without modifications
• 401 Unauthorized: Authentication is needed to access the resource
• 403 Forbidden: The Server understood the request but for some reason is refusing to fill it.
• 408 Request Timeout: The Client didn’t complete request in the time the server was willing to give it.  The client may try again some other time

Error Code 402 is a unique case.  It is reserved for future use and indicated Payment Required

500 Server ErrorsWhile 400 errors imply that the Client was the source of the fault, 500 errors imply a problem with the server.  There are 2 that I find a need to wrangle with regularly

•  500 Internal Server Error: Something went wrong and the server is crying uncle
• 503 Service Unavailable: The Server is experiencing technical difficulties.  I usually this is caused by a runaway memory leak in apache or by a sudden spike in load that overwhelms the stack.

While I in no way intend for this to be a comprehensive guide to the http response codes, there’s a much better one available from the W3C.  I thought this might provide a handy refresh and reference.  

It’s official. Web based and Desktop applications have duked it out for over 10 years and it’s pretty obvious that the web is about to run a victory lap. Sure, we still use traditional desktop apps and we may do so for the next 10 years or longer, but web based applications are clearly the winner. The smoother deployment, persistent centralized storage and more consistent deployment environment give web based systems a darwinian advantage in a market ecosystem that favors rapid adaptation and flexibility.Unfortunately, despite its benefits, web based software has several crippling short comings.

• Only available when there’s a net connection
• Reduced client side performance
• Browser quirks
• Bandwidth limitations
• Less flexible environment
• Security sandboxes

Improving technology stands a chance of removing or eliminating many of these issues in the long term. In the short and mid range, hybrid technologies are emerging that will help get us from point A to point B. Site specific browsers, offline storage, desktop integration technologies, mobile sites and widgets all have a roll to play in the years ahead. The web has definitely come full circle and as web developers we need to prepare ourselves for the next frontier of development: the desktop.

As AJAX & Javascript developers we use HTTP daily, but we sometimes forget the actual data that flows down the wire. Our frameworks, toolkits and browsers have abstracted it all away. Although a knowledge of http is not as important as it used to be, it still comes in handy things go pear shaped and you need to debug. Here is the first in a collection of short introductions to HTTP.

So any HTTP request follows a relatively simple format:

• A first line
• An optional collection of header lines
• CRLF ( An Empty Line);
• Message body

All initial lines and headers need to end in CRLF although the specification calls for lines ending LF be gracefully handled. (CR is ASCII Value 13 LF is ASCII Value 10 );

The Initial Request Line

For Requests

A request line has three parts, the method of the request, the path and a reference to the version of HTTP being used.

For example:

POST /blog/action/do_something.php HTTP/1.1

The acceptable actions are GET, POST & HEAD with GET being the most common. Method names are always written in uppercase. Similarly, the HTTP version always takes the demonstrated form.

Response

The initial response line is also known as the status line and contains the HTTP version, followed by a status code and an English “reason phrase” for the code. For example:

HTTP/1.1 301 Moved Permanently

Header Lines

Header lines provide meta-information about the request. If a message body is included they usually contain a Content-Type that returns the mime type of the body and Content-Length which returns the size of the body in bytes.

In HTTP 1.1, the Host header line is required to enable servers to differentiate between various top level domains that may reside within the server when processing requests.

Message Body

The message body contains the actual meat of the transaction. Usually this is going to be an html or xhtml document but could contain any binary or other file.

Next Time: Get Post & Head

If you don’t already know about Namespaces, Here’s a quick primer.

A namespace is a unique identifier for a particular library or collection of objects.  Namespaces are used to prevent conflicts between various libraries and to simplify debugging.

Traditionally Namespaces are defined using the unique name of a given project or library followed by a subsequent functional grouping i.e. (Yahoo.Util).  There is also a tradition from the Java community of defining namespaces & packages using reverse URL notation i.e. (com.ajaxbestiary.libraryname)  I’ve found this notation to be too cumbersome for most Ajax projects.

Abbreviating Namespaces 

Some developers prefer to abbreviate namespaces using a shorthand variable notation ie (var yu = Yahoo.Util).  This technique should be used quite carefully as it can lead to conflicts and confusion in multi-library & multi-person development.  My recommendation is that any abbreviations be standardized upon across all development within an organization.

Over the next few days I will be exploring the use of namespaces in common Ajax toolkits.

Today we conclude our series of posts on space & dimension with an exploration of YUI’s Spacial capabilities. Many of YUI’s capabilities aren’t readily apparent from the component level documentation. One exception are the setXY & getXY functions.

• setXY & getXY operate on the top left corner of an Element relative to the top left corner of the document.
• A companion getXY is provided with the YUI event object to determine the location of clicks.

A look at YUI’s API’s reveals a second, powerful class for dealing with 2d space. The YUI region class is a representation of an object on a grid. Region provides the top, left, right & bottom locations in a rectangular shape. Region is not a tool for manipulating the dom, rather it is a utility class for determining the union, intersection, area and other properties of a defined rectangular area.

YUI lacks many of the capabilities for handling scrolls, widths & heights we’ve encountered in other toolkits but still provides a reasonably capable set of tools with which to handle locations within a document.

Today we continue our series exploring the way spacial data is handled in Javascript toolkits with a look at mootools.  (Read Previous Installments on jQuery and prototype).   Similar to prototype, mootools includes dimensioning information in the Element Object.  Unlike prototype, mootools includes positioning information there as well.  Window & Document level information is contained separately in Window.size.js

Element Dimension & Position Properties (Element.Dimensions.js):

•  scrollTo(): Scrolls an element to a specified position (in some toolkits, scroll to scrolls the container to the specified element).
• getSize(): Returns an Object representing all size & scroll values of the elemen.
• getPosition(): Returns the real offsets of the element (relative to document).
• getTop: Returns the top position of the element (relative to the window).
• getLeft: Returns the left position of the element (relative to the window).

The Window dimensions (Window.Size.js):

• getWidth: Returns width Window
• getScrollWidth: Returns width of Document
• getHeight: Returns height of Window
• getScrollHeight: Returns height of Document
• getScrollLeft: Determine current left offset of viewport relative to document.
• getScrollTop: Determine current vertical offset of viewport relative to document.
• getSize: Same as Element.getSize.

Next time, we’ll look at YUI.

If you haven’t heard already, OpenSocial is a multi-vendor Social networking API similar to the Facebook API’s.  It is also, a very different environment from the Facebook API’s you may already be using.

If you’re not already familiar with Facebook development, It’s pretty much a one way street.
You deliver a page marked up in FBML (A facebook specific markup language) to facebook in response to requests from facebook. More importantly, Your application lives solely in the Facebook realm  you can really only push data to it.  Put simply, what happens in Facebook, stays in Facebook.

The new Open Social standard is a significantly friendlier place to deploy applications for several reasons.

• No need to use FBML, HTML & Javascript work just fine.
• You can use whatever Javascript Library you want, OpenSocial uses it’s own namespace to prevent conflicts.
• Persistent storage, You don’t need to handle everything on your server and an application can be written exclusively in javascript + html without any need for a server backend.  All data can be stored to the social network.
• Universal Feed.  All OpenSocial apps can write to a shared Activities feed.
• Universal Friends.  Friends can transfer seamlessly between Open Social applications
• You can brand & Host yourself.  Unlike Facebook, you can pull data into your application instead of solely pushing it into the Facebook world.

You can find the OpenSocial API’s at http://code.google.com/apis/opensocial/

D’bug has published a wonderful list of techniques for abbreviating Javascript and improving performance.

You can find the article here:

http://blog.reindel.com/2007/11/01/javascript-shorthand-tips-and-tricks/