On 10 May 2012 19:33, Mark Nottingham <
mnot@...> wrote:
> While we could us a prefixing / base url approach, I'm reluctant to add that level of complexity / processing to JSON. Thoughts?
Nah. For the sorts of cases that I'm thinking of, a href-vars can
either use the full URI or
BTW, hyphenating the names of variables is fairly toxic.
> Can you be more specific? What needs to be versioned, in your view?
That's a loaded question. But a good one.
I've seen people up-version representations without changing the
content type. I suspect that is what Accept-Version and Version is
used for more often than not. But that's not the answer.
I'm thinking more of semantics. The question of how I change the
semantics attached to a given resource is a hard one to resolve.
While the "right" answer is "never, make a new resource with the new
semantics", in reality this offers other challenges. Especially if
you aren't actually creating URIs yourself because some fool gave away
naming rights to your clients - not that I'm bitter about that or
anything...
For instance, I'm not entirely clear on how a resource might gain an
expanded range of values of an enumerated field without signaling this
through content-type (and allowing every other PUT/POST to fail when
some proportion of the population of "widgets" don't accept the new
content-type).
Nit: Sec5, p3: s/. this/. This/ ; s/may/could/
_______________________________________________
apps-discuss mailing list
apps-discuss@...
https://www.ietf.org/mailman/listinfo/apps-discuss
