On Tue, Jun 11, 2013 at 9:52 PM, michael hancock <[email protected]> wrote: > That is not what I asked for. The discussion is about alternative designs > for handling REST API versioning. For REST API's I see versioning as content > negotiation. > > For example, > > GET .../api/nodes > Accept: version=2.0 > > is like asking for version 2.0 of the document at .../api/nodes. I don't > necessarily want the latest version of .../api/nodes, but version 2.0 which > my client knows how to handle.
True, but the URI structure is also versioned, so the entities at a URI will change from version to version. In other words, ../api/nodes may mean something completely different, or even be meaningless, in API version 3. So this isn't content negotiation, which would imply that the API versions just change the representation of the same entities. This is assuming, of course, that the puppet devs haven't chosen to design immutable URIs. I think that would be a very limiting decision, but if that's the case then I don't see any reason to version the API at all: just design the representation to be forward-compatible (e.g., by only ever adding keys to a top-level hash). Forward-compatible representations are a good idea anyway, of course, and can drastically reduce the need for new API versions. Dustin -- You received this message because you are subscribed to the Google Groups "Puppet Developers" 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]. Visit this group at http://groups.google.com/group/puppet-dev?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
