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 <mee...@cilux.org> 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 >