Google Groups

Re: REST, verbs, and XDR

Terren Suydam Apr 24, 2012 2:08 PM
Posted in group: API Craft
Hi Duncan,

Well it's answering a much bigger question than the one I originally asked :-]

Definitely seems like an idea with tons of potential. One question
that immediately comes to mind is about the robustness of the public
object definitions. What if my API requires a slightly different
object model than the one defined in the Object Network?  Are they
extensible?  Does the success of this endeavor require forcing
disparate APIs into agreeing on standard object definitions even if
those definitions aren't optimal to a particular API?  If so who gets
to define the objects?

Also, I don't see any documentation on what object formats have
already been rubber-stamped, if any.


On Tue, Apr 24, 2012 at 3:43 PM, Duncan Cragg <> wrote:
> Terren:
>> .. XDR object only does GET and POST. I'm in favor of the idea of using
>> verbs like DELETE in principle, but practically speaking it doesn't make
>> sense in our case.
> Use the Object Network - it /only/ uses GET and POST!
> It uses GET to pull and POST to push domain content between collaborators.
> All the interesting stuff is in the content being moved like that.
> It thereby cleanly separates the concerns of hypermedia transfer at the HTTP
> level from the domain- or application-level interactions that are occurring
> within the body, the content, the Media Type. It's simple and clean.
> This is in contrast to the currently dominant REST pattern, based on
> AtomPub, which is essentially a lower-level data editing protocol, where
> resources are seen as updatable and deletable by these, less-supported, HTTP
> methods.
> Of course, AtomPub is often repurposed to higher-level functions, in a way
> that requires those functions to be cast into this data editing model.
>> What's the best way to communicate the VERB if we choose not to use the
>> HTTP standard?
> Using just GET and POST /is/ fully and correctly using the HTTP standard,
> not just by the letter, but by the greatest degree of deployment - thus more
> self-descriptive, thus more RESTful.
> What do you think of this approach? Does that make sense to you? :-)
> Cheers!
> Duncan