This is Ruben Verborgh's Typepad Profile.
Join Typepad and start following Ruben Verborgh's activity
Join Now!
Already a member? Sign In
Ruben Verborgh
Recent Activity
No, that's indeed a solution. Just a pity that it was decided to make OPTIONS non-cacheable—now we have the choice between an extra HTTP request or a noisy representation. Luckily, the automated discovery mechanism remains intact.
While I also was in favor of OPTIONS, mnot points out some counterarguments: http://www.mnot.net/blog/2012/10/29/NO_OPTIONS How about we use just HTTP linking to a description and then GET?
@dret Thanks, that was indeed where I was going. Especially the decision of when to use a media type and when to use a profile could be an interesting topic. Perhaps Accept-Profile could make media “subtypes” (like +json etc.) obsolete and allow much more fine-grained control.
Toggle Commented Sep 12, 2013 on AtomPatch, or: Composing Media Types at dretblog
I like the idea of being able to create specific functionality and affordances by composing it from more elementary pieces. I might have missed this previously, but how can we negotiate on the supported profiles?
Toggle Commented Sep 11, 2013 on AtomPatch, or: Composing Media Types at dretblog
That makes a lot of sense, thanks for clarifying!
Toggle Commented Nov 28, 2012 on Identity and REST in the Cloud at dretblog
I'm confused when you say that http://amazon.com/bestsellingbookoftoday is not a (stable) identity. After all, that URL is an identifier, and it identifies a resource. And that resource is thereby the identity. Since resources are temporarily varying membership functions, I'd say that yes, that URL does identify a stable identity. The fact that the *identity* can correspond to different *entities* at different points in time does not matter—what matters is that it will at any point in time be “the best selling book of today”.
Toggle Commented Nov 28, 2012 on Identity and REST in the Cloud at dretblog
This is an interesting approach – but are the two different URIs really necessary? While I like the mechanism "token/definitive URI", I don't see the benefit of actually having two URIs. Would this proposition, with only one URI, have different effects? 1. GET for template and token URI (no resource created yet) 2. PUT to token URI – the token URI was an uninitialized resource (404) but no becomes a resource (200) I think it still has the same benefits, but a little less complexity. And also: how is your token generation going to work? Do you use GUIDs or an incremental counter (which could insanely increment without serving a purpose)?
Toggle Commented Nov 7, 2011 on Creating Resources with GET/PUT at dretblog
Ruben Verborgh is now following The Typepad Team
Nov 6, 2011