API Versioning (REST Fest 2011)

API Versioning (REST Fest 2011)

Ben discusses two different methods of API versioning and argues how one form might be more RESTful than the other, while the other form is more practical and easier to develop against.

0c217b9a7dd0aa31ed40bd0f453727e1?s=128

Ben Ramsey

August 20, 2011
Tweet

Transcript

  1. API Versioning 1 Ben Ramsey • REST Fest • 20

    Aug 2011
  2. Popular versioning 2 http://api.example.org/v1/

  3. Lots of folks do this 3

  4. Lots of folks do this • http://api.twitter.com/1/ • https://api.del.icio.us/v1/ •

    https://api.foursquare.com/v2/ • http://api.linkedin.com/v1/ • https://api.paypal.com/2.0/ 4
  5. But there are problems 5

  6. But there are problems • Client needs to be aware

    of the URL • No clear upgrade path • Clients need to change all their URLs and push out updates (think about desktop and mobile clients) • Need to communicate deprecated features and phase them out over time • Developers need to be very active in the community to keep up-to-date • Other problems? 6
  7. Hypermedia versioning 7 Accept: application/vnd.moontoast.orders+xml;version=2 Accept: application/prs.ramsey.foobar+json;version=3 Accept: application/x.myservice+xml;version=1

  8. Benefits • Hypermedia • Evolvable • Upgrade path • Clients

    can specify version preference: 8 Accept: application/x.myservice+xml;version=1;q=0.5, application/x.myservice+xml;version=2
  9. There are problems here, too • You should register your

    media types with IANA:
 http://tools.ietf.org/html/rfc4288 • Developers need to support your media type • Other problems? 9
  10. Which should you use? 10 Let’s discuss. Ben Ramsey benramsey.com

    @ramsey