earlier replies
Replying to @stilkov
@stilkov That trend bugs me to no end.
1
@clemensv The trend of putting them in, or leaving them out? :-)
1
@stilkov quickmeme.com/meme/3s1aqq/
1
4
3
@clemensv @stilkov how should versioning of api's be done correctly then?
2
@YvesGoeleven @clemensv I don't even know what "versioning of the API" is supposed to mean. Version your format, relations, & documentation
1
1
@stilkov @YvesGoeleven "/v2/" says "all my resources changed in a breaking way all at once" - i.e. it's not a version but a different svc
6
9
5
@clemensv @yvesgoeleven *Exactly* the point.
2
@stilkov @clemensv @yvesgoeleven There's definitely an industry standard here. It's to put the version number in the URL.
2
@smarx @clemensv @yvesgoeleven Even if this were true, I don't see how that proves anything. Lots of bad standards out there.
1
@stilkov @clemensv @yvesgoeleven Okay, then give an argument for why the version number in the URL is bad. I honestly can't think of one.
6
Replying to @smarx
@smarx Because then you are forced to change all of your existing identifiers without any reason at all. URIs are not APIs.

Dec 5, 2012 · 8:38 AM UTC

2
1
1
Replying to @stilkov
@stilkov I guess I don't understand what you're proposing. Version in a header instead?
1
@smarx No. Don't version, or if you absolutely need to, use different media types. Check out @mnot's post on the topic: mnot.net/blog/2011/10/25/web…
1
1
more replies
Replying to @stilkov
@stilkov @smarx client-burden of implementing version-awareness in each endpoint call is really huge. Which tells me why not popular.