The biggest insight is *why* do REST at all? The main reason, to me at least, is because it allows you to leverage off-the-shelf HTTP caching. This is true even if you don't follow HATEOAS in full. It's true if you version via accept headers or if you version within the URL (either in the path or with a query param). Decent caches will play nicely with ETags, expiry times, etc. and will recognise that a PUT request is going to invalidate a path. On a large enough scale, something like Varnish will even offer a lot of benefit when dealing with short cache times (1 second and under).
Sure, versioning via the accept-header is nice. I usually do this AND offer a URL versioning scheme to make browser testing easy. It's easy enough to do in a decent framework (which probably means one of the Scala offerings, sorry), though I imagine the overhead in something like Spring might make one of Churchill's speeches look snappy by comparison. Beyond that... You'll need to assess your own requirements (both present and anticipated) before going any further. Going "by the book" isn't automatically the right answer. On 31 January 2014 09:58, Rakesh <[email protected]> wrote: > Hi, > > ok be honest, how many of you actually do it all the way? > > So many times I hear teams saying they have designed a RESTful > interface but when you dig further you find: > > 1. Only GET and POST requests > 2. versioning in the urls > 3. Clients store all the urls for the service in configuration locally. > > Is doing it 'by the book' just a fallacy and to difficult in practice? > > I've just tried explaining the notion of having the client only know > the root url of the service and be given valid paths for where to go > next so the clients don't store all the urls. > > Blank faces. > > Instead of versioning urls, we can use the Accept header to specify > the version of the API the client needs. > > Even more blank faces. > > We currently have a very poor API and have the opportunity to do it > again properly. Should I fight to do it properly? Or be content with > just getting GET/POST/PUT/DELETE used correctly? > > The idea of telling the client where to go next is very powerful to me > (its basically a state machine right?) but its complicated to > implement and new territory for the devs (me included). > > I'm also loathe to do it with a framework but if its to hard to do > manually, I'll probably drop it to. > > Any insights? > > Cheers > > Rakesh > > -- You received this message because you are subscribed to the Google Groups "Java Posse" 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/javaposse. For more options, visit https://groups.google.com/groups/opt_out.
