Yahoo unREST

Saying that they use REST is a misnomer. What they actually use is Browserland HTTP.

Case in point:

By default, Yahoo! Web Services return output in XML format. Some, but not all, of the Yahoo! Web Services can also return Serialized PHP. To get output in Serialized PHP format, use the output=php parameter in the request:

http://api.search.yahoo.com/ ImageSearchService/V1/ imageSearch?appid=YahooDemo &query=Madonna&results=1 &output=php

The RESTful way to do this is with an Accept Request header field.

I did point this out to Rasmus during a Web Services BOF at FOSS.in to which he said that it was easier to call it REST than call it HTTP. I don't buy this. A web developer will be much more familiar with the word HTTP (the thingy you see in the address bar of your browser and in the URI I've quoted above from Yahoo!'s own documentation) than with the word REST (an architectural style for distributed hypermedia systems described in a dissertation by Roy T. Fielding).

Now that that's out of my system, I really like what they are doing with PHP, especially this. I'm using Serialized PHP for representations as well in a web application I'm working on using Inertia with the following media type: application/x-serialized-php.

Browserland HTTP

All this talk about Lo-REST and Hi-REST is so misleading.

There arent two types or levels of REST. There are just Components that support HTTP to various degrees and that is where the problem lies.

For the most part we are trapped in Browserland HTTP:

• Availability of only a subset of the HTTP methods (GET and POST).


• Visibility/Awareness of a subset of the REST Data Elements (resource identifier and representation).


• Cookies!


• Limited or no control of conneg on the client side.


• Broken HTTP Authentication Interface.


• No true client-side state.

The people making the argument that Browserland HTTP is "what’s been proven on the web" and REST is just theory, "speculative", "unproved in practice, and unlikely to be a game-changer" haven't been paying attention.

State of REST

When you get REST and then go back to the drawing board to design your web application/service you realize that we've cornered ourselves in Browserland HTTP and that is the really tragedy of REST: The only protocol that follows the REST architectural style is crippled by its current infrastructure.