On Wed, Jun 12, 2013 at 8:44 AM, Deepak Giridharagopal <[email protected]> wrote: > On Tue, Jun 11, 2013 at 7:52 PM, michael hancock <[email protected]> wrote: >> >> On Tuesday, June 11, 2013 9:26:06 PM UTC-4, Dustin J. Mitchell wrote: >> >>> On Tue, Jun 11, 2013 at 12:41 PM, Daniel Pittman <[email protected]> >>> wrote: >>> >> There should be a /latest/ link that points to the latest API version, >>> >> too. If such a thing does not exist in PuppetDB, then I think that'd >>> >> be the better feature request to make. >>> > >>> > This would be a fundamental mistake, however. Why? >>> > >>> > Because if the API changes, your client isn't going to work! >>> >>> True, but this is what the OP asked for! >> >> >> 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. > > Other than the philosophical reasons for switching to versions in a header, > are there any practical reasons to do so? Seems like a "six in one hand, > half-dozen in the other" kind of situation to me. Such a switch wouldn't be > difficult to do, but I'd like to understand what improvement in user > experience that would bring about.
Yes: a "Fielding" style REST resource has a URL. Not "one URL per version", but one URL. You can use the generic URL comparison rules to determine identity of data objects, and rely on it for caching. Standard HTTP use `Vary` headers and the content negotiation headers to determine document identity and form. In the same model, navigation is done via hypertext in the retrieved documents, not through clients knowing the URL structure; in general, you shouldn't publish anything but the entry-point like and the relationship types to the client. These are a key part of delivering the promises of REST: that you can build a system capable of anarchic growth to billion system scale, with an unknown but massive number of people building and operating their own servers, without any central coordination, while still delivering efficient client and intermediate system management of assets. For PuppetDB, none of those advantages are compelling, I think, since it is focused on machine to machine operations, not human-focused document delivery, and especially not on allowing unrelated parties to build interoperating servers that host PuppetDB content in a transparent way. -- Daniel Pittman ⎋ Puppet Labs Developer – http://puppetlabs.com ♲ Made with 100 percent post-consumer electrons -- 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.
