IMHO when building a web service /node/10 URI is just not enough. I would use something like /1.1/node/10 which first arg is actually the API version.
We're not 100% sure if entity REST URIs are going to stay the same in next drupal versions or even minor updates.
I might have to change it to 1.2/n/10 in future, who knows. I can build web services in a custom module but I'm shaky implementing entity URIs for a long term development if it confuses users later on.
There are ways other than using a prefix version URI, but it's the easiest, even twitter uses it like this: https://api.twitter.com/1.1/statuses/home_timeline.json
Comments
Comment #1
sourcesoft commentedI know how Hypermedia tries to fix Server URI scheme changes so it doesn't break clients code, But it's always not the best solution using HAL.
Comment #2
vijaycs85not sure how much it is particle, but yeah, we need version system.
Comment #3
sourcesoft commentedAs you mentioned yourself it's been discussed here too: https://drupal.org/node/1046470
And as a best practice: http://stackoverflow.com/questions/389169/best-practices-for-api-versioning
Comment #4
clemens.tolboomI vaguely remember from @DrupalCon a discussion about adding the API version into the request header. Not sure though. [edit]Discussed also in #1046470-5: Prepare for versioned services[/edit]
Related to this is #1925618: Ensure Drupal's web services are self-documenting: Swagger support OR rest_api_doc to Drupal core as an experimental module?
Comment #5
Crell commentedI think we made the conscious decision to NOT use URI versioning. As of yet we don't have any header-based versioning. We can look into adding that in D8, or just start doing so in D9 when there's actually a change. :-) I think I'd rather discuss that over in #1046470: Prepare for versioned services
Maybe won't-fix this?
Comment #6
Crell commentedClosing per discussion in IRC. We should restart the discussion in #1046470: Prepare for versioned services