So, I'm busily evangelizing REST in my company, because it "just feels right" to me, but... there are practical problems to solve!
For example, what would a REST geocoder look like? The application is bascially all service, no resources.
Subscribe to:
Post Comments (Atom)
4 comments:
I think that even rest gurus have admitted that some things do belong in the query string portion of the url. Anytime you are searching for something it means that DON'T KNOW its URI - if you knew it, it wouldn't be a search, it would be request. If there was anyway to rest-ize a geocoding service, I think it would be to provide a standard URL format for addresses - if you know the exact address and how to component-ize it, you can just use that URL format to get the location back. If you don't know the exact address details, you use the address query tool, which would return you a list of links to the exact addresses that match your address query. Unfortunately there are so many different address formats that coming up with a way to encode all of them into a URL in a standard way is quite difficult.
Maybe something like:
http://www.geocoder.com/location/Some_Country/Some_Region/Some_City/West/Some/Street/1207/Unit/105A
I first tried the reverse, more human-readable standard, then realized that a hierarchical top-down approach might be more web-like. Where to put the the postal code, if at all? Even with such a url, because of the nuances of street names (affixes galore) it will still require a lot of work to parse such a request - might as well be a just query string.
Paul, it's all about algorithmic resources. For example:
http://www.google.com/search?q=Paul+Ramsey+REST
is an algorithmic resource, one which happens to return a bunch of links to other resources. It would not be more strictly RESTful if it was .../search/REST/Ramsey/Paul.
Likewise, a RESTful geocoder could have algorithmic resources like:
http://gis.example.com/geocode?q=10+Downing+Street
Where the GIS industry tends to go off the rails is treating GET and POST requests to the same URL as equivalent, or putting the resource scoping ("10 Downing Street" in this case) inside the request body. Avoid these pitfalls and you're on the right track. Don't obsess unnecessarily over URL design.
In fact the double-pump nature of many geocoding services is exactly suited to the less-oft mentioned part of "REST" which is State Transfer. A geocoding query often results in some questions to disambiguate addresses. Did you mean East Kirby, or West Kirby? Each of these would be hyperlinks back to the search. The representation of the answer surely is a URL-able resource; it is probably a canonical address in a nice human and computer readable form, as well as some GML or KML or something giving the coordinates of the address. So your geocoding REST client would pass on a query for an address as suggested by Sean, it might get the straight up answer, or it might get another resource which contained links to the real answers, links which would effectively have to be followed by a human.
it occurs to me that a strong distinction has to be made between situations where a logical query with some known bounds can be made, ie a street name and address in some reasonable form, vs explorations of a larger kind.
Sometimes, you cant know or guess what to ask, even to find out the next possibility! hence the need for lists of defined options.
REST feels right to me - all the better to get to know it well
Post a Comment