Zato-ish way to create versioned API with Zato?

Hi Zato!

I couldn’t really find a discussion about this, so thought I’d start a new topic:

What is the Zato-ish way to create a “versioned” RESTful api using the approach described here?:

http://amberonrails.com/move-fast-dont-break-your-api/

My first thought was to create a SimpleIO transformation service, used by the main API services to respond to the Accept Header.

Just curious about thoughts on the design of this in Zato context

Hi Sam,

I’ve read this article but I’m not clear about the most important part - how does one ensure that new gates are taken into consideration by already existing API services? Do programmers need to update code?

Also, how do the gates work when a new parameter is mandatory for all users?

@dsuch the design principle is to create some means to “transform” sequentially back through API versions. So programmers update a translation service with the sequential differences.

If a user of the API requests the service with no version specified in the Accept Header, they just receive the most recent version (some API implementers then peg you at that version, and give you a means to change your default version, Stripe does this). Or, if you specify a version, then you use the documented way for that version, the transformation service transforms the call, service is processed, and translated on the way out.

So, the code for your main service just keeps moving forward, and you account for the differences in your transformation service based on API version.

Also, how do the gates work when a new parameter is mandatory for all users?

If you are working with “versioned” API, and you make a new parameter mandatory for all users, you are basically telling all users they must cease using the version they were working with to date.

I realized the following:

If someone wants to support running “versions” of a published API and use zato, they can actually just put a “version” in for instance the “Accept” header in their client side request to the zato http (or http REST) service, and then the channels/endpoints can remain unchanged, but the data may change depending on the “version”