A Proposal for RESTful Location-awareness

Earlier this month the Mozilla Foundation announced Geode, an early implementation of a draft W3C specification for browser-based geo-location. The abstract of the draft specification states its mission to define "an API that provides scripted access to geographical location information associated with the hosting device." A quick read of the draft W3C Geolocation API Specification got me thinking about how else such functionality could be implemented in the browser and used by web services.

The draft defines an API to be made available to any Javascript running in the browser. While the browser itself is responsible for getting the user's current location from the operating system, it's client-side Javascript that makes use of this location information. Provided in the draft are examples like the following:

function showMap(position) {
  // Show a map centered at (position.latitude, position.longitude);
}

// One-shot position request.
navigator.geolocation.getCurrentPosition(showMap);

Such an interface allows for a high-level of interactivity on the client-side as Javascript controls and has access to all aspects of the client's location information. However, I feel this comes at the costs of a standardized location format and portability. First, if the client wishes to gather information from a web service using the current location as a parameter, the client-side script must encode and transmit this information to a server. The format in which this information will likely vary greatly. One developer might choose to transmit this information in this manner:

http://nearestfood.com/pizza?lat=1.234&long=1.234

Another might transmit this same information another way:

http://iamhungry.com/pizza?latlong=1.234,1.234

There is no standard in how the client's location is represented. Second, the client must support Javascript, which in the case of mobile device clients, is not yet a given.

One solution is to transmit client location information via a standardized request header field similar to Accept-Language. For example, we could add Client-Location to the existing set of header field definitions. The format could look like the following:

Client-Location: lat=1.234, long=1.234

By amending a new standard field definition we gain two advantages. First, there is a consistent format in how the location is represented. Second, the client does not need Javascript to transmit location information to the server. More importantly, the client no longer needs be a browser, but anything capable of making HTTP requests: from HTTP clients like wget and cURL to other web services.

Let's see how our request header field implementation fulfills the requirements set in the W3C draft specification:

  1. Find points of interest in the user's area

    A request is made to a web service containing points-of-interest data. The server reads the user's location from the request header and returns appropriate information.

  2. Annotating content with location information

    When a POST is made to a web service, the server application reads location information from the header and annotates the POSTed resources appropriately.

  3. Automatic form-filling

    When a request is made to the server, the headers are read and the address portions of the form are pre-populated with the address of the user's current location.

  4. Show the user's position on a map

    When a request to a mapping service is made, the displayed map is automatically centered on the location given in the request header.

  5. Turn-by-turn route navigation

    The client must periodically poll the navigation service, sending the user's new location each time in the request header fields. Careful use of caching and Etags should minimize some of the negative effects of polling.

  6. Alerts when points of interest are in the user's vicinity

    Same as #5.

  7. Up-to-date local information

    When a user makes a request to a news service, the server narrows down the returned content to what is relevant to the user's locality deduced from the request header fields.

  8. Location-tagged status updates in social networking applications

    Each time the user POSTS a status update to Twitter or Facebook, the server annotates the user's new status with the location information read from the POST request header.

As you can see, it doesn't look like we will lose any functionality with a request header field based implementation, but we will gain portability and consistency.