This is a single archived entry from Stefan Tilkov’s blog. For more up-to-date content, check out my author page at INNOQ, which has more information about me and also contains a list of published talks, podcasts, and articles. Or you can check out the full archive.

Backpack "Web Services" API

Stefan Tilkov,

Backpack gets what they call a Web services API … I don’t have the slightest idea what this is supposed to be. It’s neither Web services nor RESTful nor anything else I’ve seen — it looks like bad re-invention of SOAP to me.

Update: Be sure to check out the comments.

On May 18, 2005 4:31 PM, David Heinemeier Hansson said:

It’s just XML over HTTP. We didn’t see a need for wrapping that in further complexity. Just like the “REST” API for Flickr. Or 43things. Or even Amazon. Lots of examples of people just doing XML over HTTP without having any aspirations to do a Web Services thing when they’re happy just doing web services. We can get by without capitalization ;)

On May 18, 2005 4:42 PM, Stefan Tilkov said:

David, I’m not suggesting you should switch to WS-*, SOAP etc. In fact for your use case that would probably the worst thing you could do. But there’s lots of benefits in following REST principles when designing an XML over HTTP API, and maybe you should consider doing so.

On May 18, 2005 4:55 PM, David Heinemeier Hansson said:

Sure. I’m just saying that we’re hardly without predence. You’re not finding PUT or DELETE verbs being in use by neither flickr, 43things, amazon, or many others just doing XML over HTTP. So there’s varying degrees of RESTful compliance. In some aspects, Backpack is a lot closer than others mentioned by using distinct URIs, like /ws/page/123 and /ws/page/123/items/list. Instead of just /rest?query=X.

Backpack isn’t more RESTful because we didn’t spend a whole lot of time on it. All the methods exposed through the API are just the regular ones we use for the web too. Slightly modified in some cases for the return format (xml instead of just html).

REST is a nice ideal. People should definitely strive for it. We are. But labeling anything but complete compliance as a “bad re-invention of SOAP” seems to both miss the point (we’re a bad implementation of REST, if anything) and be a turn off in general.

On May 18, 2005 5:10 PM, Stefan Tilkov said:

My reason for the SOAP comparison is that it’s similar to SOAP 1.1 in sending everything, even retrieval ops, through POST. Other aspects I don’t like are the usage a a developer token (what’s wrong with basic or digest auth) and the use of a non-standard header to get a different representation (instead of using the HTTP Accept header with MIME types).

As for the turn-off thing: please do note that I’m actually a big, big fan of your RoR work; that leads me to expect and accept nothing but the best from a Dutch mastermind :-)

On May 18, 2005 5:26 PM, David Heinemeier Hansson said:

Actually, you can use GET for things that are natural GETs. So GET /ws/page/123?token=xyz will actually work. The header thing is likely going to be replaced by just using content-type. We’re also looking into the X-WSSE approach to authentication, but quick won over perfect.

On May 18, 2005 5:31 PM, Stefan Tilkov said:

Sounds good — looking forward to future versions, then.

On May 18, 2005 7:31 PM, jsled said:

I’ve tried to call these non-REST, non-SOAP RPC interfaces SHAREd services: Simple HTTP API of RPC and Encoded data.

WRT the RESTfulness of the Backpack API… re-inventing Content-Type as ‘X-POST-DATA-FORMAT’ is just silly. Why doesn’t anyone just read the HTTP spec, it’s easily digestable? And while the resources seem to have distinct URIs, they’re nowhere in the data returned from API requests, which is weird.

Open APIs rock; Backpack should be commended.