1

I am implementing a simple web application with python (3.x) and bottle. As the APIs I want to expose might change in the future, I would like to add the possibility to have different versions.

On this topic there are some insightful answers here, but unless versioning for web APIs is a proven bad idea I'd like to give it a try anyways.

Regarding my app: for example, while version 1.0 allows the following call through a POST /resource:

@post('/resource')
post_item(name=item_name, value=item_value)

a future version might do:

@post('/resource')
post_item(name=item_name, value=item_value, fullname=longer_item_name)

For simplicity assume the keyword parameters 'name', 'value', 'fullname' come from the FROM data fields:

<input name="name" type="text" />

Now, the first thing that comes to mind is inserting a version parameter at the beginning, something similar to what IP is doing with its headers:

post_item(v=1, name=item_name, value=item_value)
post_item(v=2, name=item_name, value=item_value, fullname=longer_item_name)

However, it seems a bit cumbersome. Is there any web micro-framework library that helps with this? Am I falling outside what a micro framework does?

Community
  • 1
  • 1
lorenzog
  • 3,483
  • 4
  • 29
  • 50
  • why don't you like the "one application per version" thing? – redShadow Mar 18 '13 at 23:21
  • Is this really necessary? Can't you simply use declare it as `def post_item(**kws):` and use as many values as possible? – A. Rodas Mar 18 '13 at 23:27
  • I'm not sure what your question is. Are you asking how to version a web API (a [broad question that doesn't have one "right" answer](http://stackoverflow.com/questions/389169/best-practices-for-api-versioning)) or looking for recommendations on libraries that implements such versioning in bottle (a subjective question with no right answer) or trying to determine how to have bottle handle two versions of the same endpoint depending on a value (there might be a question here, but I'm not sure if that's what you're going for). – Mark Hildreth Mar 18 '13 at 23:32
  • @redShadow I'd like to see other approaches, or at least a more detailed rationale on why it's a good idea. – lorenzog Mar 19 '13 at 08:28
  • @A.Rodas that would not work as older clients might not know they can send more data through new data fields. – lorenzog Mar 19 '13 at 08:29
  • @MarkHildreth a little from column A, a little from column B, a little from column C ;) Actually, I'd like to know what's a "good enough" solution to do versioning for a web API in bottle. Perhaps I just need to hack around it for a bit more and see if an obvious pattern to do it emerges. – lorenzog Mar 19 '13 at 08:31

1 Answers1

6

It's definitely not a proven bad idea, more like a proven necessity. The issue is that there's very little agreement on the best way to handle it (beyond agreement at a high-level on URI-based approaches).

Apigee have some good articles on API versioning strategy here:

https://blog.apigee.com/taglist/versioning

Here's a good overview of how popular APIs handle versioning, along with some more resources that discuss versioning strategy:

http://www.lexicalscope.com/blog/2012/03/12/how-are-rest-apis-versioned/

Cormac Driver
  • 2,511
  • 1
  • 12
  • 10