FYI: In looking around for a list of HTTP verbs with specification mappings....I found this one (is there a better one?): http://annevankesteren.nl/2007/10/http-methods Sam Johnston wrote:
[moving this off-list discussion to the list where it belongs]
On Sun, Oct 18, 2009 at 12:40 PM, <AC> wrote:
As we move closer to practical working set of management actions, it appears we are moving further away from ReSTful principals. Now, we have 4 additional actions HEAD, OPTIONS, MOVE, and PATCH over the ReST CRUD. We haven't even begun to here from user wanting CHECKPOINT, COPY and CLONE (a live checkpoint copy).
All of these verbs are useful and none of them are particularly non-RESTful - in fact they're effectively performance optimisations: - HEAD allows one to retrieve metadata without the entire (possibly large) representation - OPTIONS allows you to "look before you leap" - COPY allows a remote client to request a resource be transferred (short for GET followed by PUT, only allows e.g. EDGE connected iPhones to participate) - MOVE is like COPY, only it's short for GET-PUT-DELETE (again avoiding the need to transfer the whole lot via the client) - PATCH is like PUT, only it doesn't require the entire entity to be transferred (rather just the changes in e.g. diff format)
Without these optimised HTTP verbs it would be literally impossible to, for example, migrate a virtual machine from one cloud to another from a client sitting on a "slow" connection like 3G/EDGE/GPRS, or even ADSL. Note also that they have all been standardised at some point by the IETF, either in HTTP itself or WebDAV.
Nobody's talking about introducing our own non-standard HTTP verbs for OCCI.
Using SSL and other secure protocols, we eliminate any possibility to leverage existing document cache infrastructures.
No, we eliminate the possibility for *untrusted intermediaries* to cache, which is by design.
As OCCI continues to mature towards practical design, many aspects of ReST seems to be incompatible with real world management applications. Outside of the resource addressing scheme, which is very similar to SNMP and CMIP/CMOT in concept, ReST provides very little to guide the direction of our technical decisions. In fact, the more I think of it, the more it looks like "snake oil". It appears to have a large following of "devotees", drinking that koolaid and blindly chant a ReST mantra. The scary part is, most don't have a clue of impacts or its proper application.
Attacking an API for being RESTful after it's been written (based on a clear consensus to be RESTful no less) is not what I would call "constructive criticism", especially when framed as a religious debate when it's not. There are plenty of forums for such "discussion" but this isn't one of them - we're assessing all the options on technical merit with a view to reaching a rough consensus and producing running code (even if we're not the ones writing it).
If you insist on having this discussion then I would suggest focusing on the content rather than the contributors, for example by highlighting specific instances where REST fails to deliver _and_ where RPC would have done a better job. Good luck with that.
Sam
-<AC>
Sam Johnston wrote:
On Fri, Oct 16, 2009 at 7:32 PM, <AC> wrote:
And, how does this impact the implementation of ReSTful principals as called out in the last draft of the occi specification ?
It doesn't. It just provides a shortcut for someone who wants to make a minor change (e.g. the number of compute cores) to a large representation (e.g. OVF for an entire cluster).
Sam
On Fri, Oct 16, 2009 at 4:09 AM, Sam Johnston <samj@samj.net <mailto:samj@samj.net> <mailto:samj@samj.net <mailto:samj@samj.net>>> wrote:
Afternoon all,
The HTTP PATCH verb is interesting in that it allows you to update a representation without having to transfer the entire thing. It's a space-time tradeoff in that it's a smaller transfer but you then have to generate and apply the patch, but for large/complex representations and remote (e.g. iPhone) users it could provide significant benefit. I wouldn't suggest that it be required at this time given lack of implementation (e.g. Apache) support but I've added a reference to it to OCCI as it will be useful for some applications and I'd rather provide the functionality than have people invent it.
It's worth noting that PATCH first made an appearance (along with LINK and UNLINK) in the first HTTP RFCs but wasn't included in more recent releases due to lack of implementations.
Sam
---------- Forwarded message ---------- From: *Mark Nottingham* <mnot@mnot.net <mailto:mnot@mnot.net> <mailto:mnot@mnot.net <mailto:mnot@mnot.net>>> Date: Fri, Oct 16, 2009 at 1:48 AM Subject: Fwd: New Version Notification - draft-dusseault-http-patch-15.txt To: HTTP Working Group <ietf-http-wg@w3.org <mailto:ietf-http-wg@w3.org> <mailto:ietf-http-wg@w3.org <mailto:ietf-http-wg@w3.org>>>
New version (-15) has been submitted for draft-dusseault-http-patch-15.txt. http://www.ietf.org/internet-drafts/draft-dusseault-http-patch-15.txt Sub state has been changed to AD Follow up from New Id Needed
Diff from previous version: http://tools.ietf.org/rfcdiff?url2=draft-dusseault-http-patch-15
IETF Secretariat.
-- Mark Nottingham http://www.mnot.net/
_______________________________________________ occi-wg mailing list occi-wg@ogf.org <mailto:occi-wg@ogf.org> <mailto:occi-wg@ogf.org <mailto:occi-wg@ogf.org>>
http://www.ogf.org/mailman/listinfo/occi-wg
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
-- Michael Behrens R2AD, LLC (571) 594-3008 (cell) (703) 714-0442 (land)