Unless I'm mistaken, using a header means that a service must consume the
message before it can tell whether or not it supports a compatible version.
It would be better to use different queues for each version and only attach
consumers to the appropriate queues. That has the additional benefit of
giving you visibility into the traffic to each version (by inspecting
rabbit queues).
As for best practices... At Student.com we have a versioned API layer
outside the "core" services. We could write a whole series of blog posts on
this but the basic structure is as follows:
We have two classifications of services: domain services and facades.
Domain services encapsulate core business logic (as in Domain Driven
Design) and facades aggregate the domains for a specific customer. For
example, we have a "mobile-facade" that contains all the APIs used to drive
our mobile apps.
Facade APIs use HTTP, are explicitly versioned and form our contract with
the specific customer. Domain service APIs use RPC and not explicitly
versioned. Each domain service release maintains backwards compatibility
with the previous one, which is verified by checking that the facade
contracts can all still be satisfied.
This structure is nice for a few reasons:
1. The facade service APIs are a well-defined contract between us and our
customers
2. We have explicit versions without having to test the explosive
combinatorials of M services with N different versions
3. We're free to deploy domain services continuously as long as all the
currently supported facade contracts are satisfied
Hope that helps!
Matt.
ยทยทยท
On Friday, March 4, 2016 at 9:46:56 PM UTC, remco....@gmail.com wrote:
Hi,
How do you use versioning of apis in nameko? I used headers in rabbit to
restrict a service only to respond to calls for it's own version, and used
urls in http paths with similar intent. What are your best practices with
nameko?Thanks for sharing!
Remco