On Mon, Apr 24, 2017 at 10:04 AM, Oleg Borisenko <[email protected]> wrote: > Hello. I want to get API-versioning functionality and I wonder how to do it > in Pyramid correctly. > Conditions: > 1) I want to have two simultaneously working APIs > 2) I want to have the following notation: > /v2/veryimportantroute > /v3/veryimportantroute > /veryimportantroute - this one should by default use some of specified > API versions > 3) I would like to make minimum changes to currently existing code > > What's the most correct way to do this? I know that I can implement some > kind of 'predispatcher' but it seems that it's not quite an easy way.
I would first question whether '/veryimportantroute' is necessary because that causes most of the complication. Can't the clients explicitly call the version they're compatible with? Or can't your view handle all request versions, either by noticing that a new argument does or doesn't exist or has a different format, or by a 'version' argument? Or can '/veryimportantroute' simply redirect to the latest version? If all the views are different, you can handle this in the view configuration, by tying route 1 to view A, route 2 to view B, and route 3 to view B. (Or a redirect view, or do the redirect in Apache/NGINX.) If it's all going to a single view, then the view may need to know whether 'v2' or 'v3' was specified. (This is equivalent to a 'version' argument, but in the URL.) If you have a single route, then the version can be a match variable. If you have two different routes, then it won't be a match variable and you'll have to determine it via some other trickery (such as a custom route predicate, or have the view look back on the path, but both of those can be inelegant. If you tell us some more about when/how you expect the API to change, and whether there will be a separate view for each version or one view for multiple versions, then we could answer it more precisely. Or if the answer is, "I don't know and I just want to generally future-proof the site", then the answer may be "We don't know what to do because we don't know what kind of need will arise". If there's only one version now, you could either put '/v1' in front of everything just in case, or leave it out until the future reveals what you'll need. You may find you won't need the version prefixes: the view can simply deduce what version the client is from the arguments, and return a response for that version. Or if a new API has actual new URLs (new views), then they'll never be called in the old version or if they are it's an error. -- Mike Orr <[email protected]> -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/pylons-discuss/CAH9f%3DupWfMjmmV8zMu8-KsZXwqvzDoPYiUe3m6cVCNzKHNYPaA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
