REST, verbs, and XDR

[Terren Suydam]

Hey everybody,

First time poster, looks like a great group here. 

Anyway, the dilemma I'm facing is how to handle verbs. Forgive me if this has been covered, as I am new to the party.

My basic problem is that I expect a significant portion of my API consumers to be browser-based. And I must support IE8/9, but it's 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.

My question is for the RESTafarians who must support IE8 and IE9. What's the best way to communicate the VERB if we choose not to use the HTTP standard?

Alternative headers are off the table since XDR doesn't allow those, either. So a url parameter? Doesn't seem like it belongs in the resource identifier.

Best,

Terren

[Mike Kelly]

Hi Terren,

Ruby on Rails uses a '_method' parameter in the POST body for legacy clients like this

Cheers,
Mike

[Kevin Swiber]

On Tue, Apr 24, 2012 at 3:34 AM, Mike Kelly <mikeke...@gmail.com> wrote:

Hi Terren,

Ruby on Rails uses a '_method' parameter in the POST body for legacy clients like this

Cheers,
Mike

Many frameworks have support for this.  Check for "HTTP method override" techniques for whatever technology you're using on the server end.  Rack (Ruby) and Express (Node.js) have method override middleware that can handle this easily.  I've also built a .NET implementation.  They typically search for the X-HTTP-Method-Override header and fallback to the _method querystring parameter. 

--
Kevin Swiber

Projects: https://github.com/kevinswiber
Twitter: @kevinswiber

[Duncan Cragg]

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

[Terren Suydam]

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.

Terren

[Duncan Cragg]

Terren:

> 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.

The idea is to re-use already agreed or popularised labels, schemas,
ontologies, vocabularies and formats, then add to that as cases come up.
After that, if your data truly is unique to your case, you get to define it!

Deviation from an Object Network type in whole or part would only be
needed to represent an actual deviation in meaning. So no deviation
means use the same format, because you lose nothing, and everyone wins!

Defining the types is intended to be a mix of community discussion with
arbitration when things get sticky! There are only a few types I've
tried and implemented - contact, event, article, media, lists, queries,
user, gui, map, site. It's all up for grabs - just join the Google Group
and let's get some stuff agreed!

You can start at http://the-object.net which has some links and basic
info. The prototypes will always be ahead of any documentation, of
course. I'm hoping to implement this approach at at least one
ThoughtWorks client here in the UK, very soon. I'll keep everyone posted
on that, in the group.

Cheers!

Duncan