Yahoo! Internet Location Platform - Part 1
As many people have noted, the Yahoo! Internet Location Platform has been released. After looking at the examples it all made sense, but two things stood out:
- Request: The use of a custom query mechanism rather than using “HTTP query strings”:http://en.wikipedia.org/wiki/Query_string.
- Response: The lack of URIs to identify related resources. (This is addressed in Part 2 of this post.)
What follows is just a quick exploration of the first of these two issues.
Query Mechanisms
The Yahoo! Internet Location Platform uses an interesting mixture of three different query syntax styles.
1. The place name search syntax looks like an object method call.
/places.q('sydney%20opera%20house')
Yahoo!‘s function-like syntax places.q(‘place%20name’) makes it look like q is a method on the places object. That would suggest the underlying implementation may have leaked into the interface (surely not!).
2. The paging parameters, start and count, are semicolon delimited strings.
/places.q('springfield');start=0;count=5
Avoiding the use of HTTP query strings would allow HTTP caches to cache the results of the place name searches. That would improve performance on common searches while reducing the load on the Yahoo! servers. However, that would prevent Yahoo! from controlling access and accurately metering usage.
3. And, query strings are still used to determine language and format of the resource:
/places.q('usa')?lang=fr
/place/2487956?format=json
There goes the caching theory, so why not just use plain vanilla query strings for all parameters and keep it consistent? Example:
/places?q=springfield&start=0&count=5&format=json&
It’s dead easy to construct a query string from a map, or dictionary, of name/value pairs and append it to a GET request. Using a non-standard and inconsistent approach creates more work for developers.
Continue to Part 2