Re: [dwbp] BP - URI structure is not relevant for REST

I meant unversioned hypermedia data APIs. When I've searched for examples, I've found a lot of articles where people argue for doing REST without versioning, avoiding the need by virtue of following the HATEOAS constraint and committing to what they have for an interface, but I haven't yet been able to find an example of a real-world data API that actually has done that successfully over time.

Weighing all the arguments, I feel like I understand the reasoning behind avoiding versioning, that it shouldn't be needed if you only ever change what's under the hood and leave the actual interface alone, but I do wonder how successful people have been in getting the interface part right the first time, or at least right enough that any revision could really be considered a different API.  I guess I don't see a big advantage to putting that "new API" at http://otherthing.mydata.org instead of http://thing.mydata.org/v2. As long as you keep both versions up and running, you don't break anyone's code. Using a version number at least helps clarify what is different. As a developer, I think it's much easier to decide to use "v2" in a new client than to decide whether to use "thing" or "otherthing". I find the example of HTML unhelpful, because what gives a web site its resilience to unheralded change is the human in the loop. Where we attempt to navigate web sites in code (scraping, bookmarking), things get brittle fast.

-Annette


On Jul 28, 2015, at 5:03 PM, Erik Wilde <dret@berkeley.edu> wrote:

> hello annette.
> 
> On 2015-07-26 23:53, Annette Greiner wrote:
>> Does anybody have an example of a successful HATEOAS compliant API that does not use versioning?
>> I'm honestly wondering, not trolling here. In order to argue for something as a best practice, it helps to be able to point to successful use.
> 
> well, i hope this doesn't sound too obvious, but HTML is a great example. you can use old pages with new browsers and new pages with old browsers. if HTML would have designed in a way where each "version" of a page would have required different URIs, and consumers somehow navigating between those, it's easy to imagine that the web's success would have been adversely impacted.
> 
> in terms of non-HTML examples, there are numerous examples of spec-level formats that have gone that way. two examples that come to mind ate Atom and DITA. both have extension and openness models that allow users to evolve the formats with additions (for example, podcasts are nothing but an extension of Atom, but not "a new version"), allowing the ecosystem of producers and consumers to evolve and grow without creating versioning rifts (that tend to impact this kind of organic growth).
> 
> cheers,
> 
> dret.
> 
> -- 
> erik wilde | mailto:dret@berkeley.edu  -  tel:+1-510-2061079 |
>           | UC Berkeley  -  School of Information (ISchool) |
>           | http://dret.net/netdret http://twitter.com/dret |

Received on Wednesday, 29 July 2015 08:09:12 UTC