• Add a Comment
  • Edit
  • More Actions v
  • Quarantine this Entry

Comments (2)

1 localhost commented Trackback

You're right on that versioning isn't factored into the picture. Versioning is a hard problem. The fact of the matter is, if the interface changes signficantly, you can easily break a client who was using and older version. There's no way around this if you're talking about a human ever writing code to 'the interface'.

I think we're in need of some best practices around evolving services akin to Eclipse's "How to evolve API" story, here: http://tinyurl.com/2spdoa . The idea is to design your services in light of the fact that they will probably be changing in the future, and planning for that ahead of time. Planning for anything. See also Steve Northover's recent post: http://tinyurl.com/2s2ymf .
I think it's also important to identify the version of your services, somehow. The eBay approach doesn't seem practical in a RESTy world; I don't want a new 'base url' for every new version of the service. It seems to me that indicating, somehow, in a machine-readable way, the version of the service you are supporting on the server, gives clients a way to say "utoh, I don't understand that version", or even better, adapt to different versions.
Good fodder for another blog post. Thanks for the poke.

2 localhost commented Trackback

Sounds like a de-enveloped JSON-RPC.

Add a Comment Add a Comment