I tried to comment directly on Bill's Blog but comments were broken again. What I wanted to say was:
I think the real tragedy of this legacy is that we currently have installed, in nearly every networked node in existance, the potential for a simple, iterative, resource-driven client that can't really speak the protocol it was designed to handle. I repeatedly find myself grudgingly writing a curl wrapper to test a RESTful API in a pinch while my browser looks at me and laughs.
Oh, and the irony that your comments button says "Post" rather than "Put" is not lost.
Hopefully comments will be fixed soon and I'll cross post, er cross PUT.
Tuesday, October 23, 2007
My Bow-Legged Master - Comment
Subscribe to:
Post Comments (Atom)
7 comments:
XHTML 5 can't come soon enough.
I'm not real close to it, but I think it will be a while.
"Oh, and the irony that your comments button says "Post" rather than "Put" is not lost."
You must have missed the bit about using POST to create. I guess that would irony heaped on irony.
"Oh, and the irony that your comments button says "Post" rather than "Put" is not lost."
POST to create - do your homework before spouting off.
This is my second attempt to comment here; the last one vanished. The irony heaped upon irony is not lost on me.
I didn't see it as spouting off at all, per the HTTP 1.1 Spec:
"The PUT method requests that the enclosed entity be stored under the supplied Request-URI... the origin server can create the resource with that URI. "
Or per Jérome Louve, creator of RESTlet, "The best method for creation in REST is PUT which is also used for updates. The advantage of PUT over POST is that if the operation fails it can be safely repeated which isn't the case for POST".
I base my blogs on actual usage of the tools, not homework.
As for the delay in putting though moderated comments, my apoligies for missing a weekend of moderation.
"Or per Jérome Louve, creator of RESTlet, "The best method for creation in REST is PUT which is also used for updates. The advantage of PUT over POST is that if the operation fails it can be safely repeated which isn't the case for POST"."
A claim that has to be qualified wrt client supplied URIs (ie Request-URI). That's one reason why Atompub allows a client to use POST to ask a server to create a resource.
"I base my blogs on actual usage of the tools, not homework."
Don't forget about every (more or less) deployed web browser, which uses POST. Actual use of PUT to create isn't common at all. If you want to count web enabled mobile phones as the fastest growing HTTP client base (afaict that's true), PUT creation is insignificant. I'm not saying that's right or a good situation, but if we're talking about actuality, that is the case as of 2007.
"That's one reason why Atompub allows a client to use POST to ask a server to create a resource."
I'm not all that familiar with Atompub so I won't comment on it other than to say that again, I agree with Jérome - PUT is intended to be an idempotent operation and one that you can safely perform multiple times over. POST has its place when creating resources that need a GUID-like artifact tacked on to the resource by the server, and I can see how that plays into Atompub. My point from the OP was more the fact that I find it frustrating that the most ubiquitous clients for one of the most successful protocols ever doesn't support fundamental methods clearly laid out in the intent of the protocol. It would be like an ftp client that couldn't get.
"Actual use of PUT to create isn't common at all."
This certainly was true, but likely because most browsers simply don't implement PUT/DELETE so it couldn't be true. That doesn't necessarily mean we should bend the meaning of the specifications simply because certain clients choose not to play by the intent. My feeling is that as we see increased use of RESTful services consumed by non-browser clients (my reference to curl in the OP), there will be a move more towards how the HTTP spec was written and PUT/DELETE will take on the meaning they were intended to have. The fact that at least two of the more popular REST frameworks (RESTlet and Rails' scaffold_resource) both use PUT for creation makes this not a totally insane assertion.
"POST has its place when creating resources that need a GUID-like artifact tacked on to the resource by the server"
More than that. POST is appropriate when the server maintains administrative control of its URI space (which of course it can).
"This certainly was true, but likely because most browsers simply don't implement PUT/DELETE so it couldn't be true. That doesn't necessarily mean we should bend the meaning of the specifications simply because certain clients choose not to play by the intent."
It's not the browsers, it's that they are compliant with HTML.
"That doesn't necessarily mean we should bend the meaning of the specifications simply because certain clients choose not to play by the intent."
Unfortunately, HTML subsets HTTP; to be a compliant forms based browser, you must support 2 verbs only.
Much broken web technology that came after HTML (Model-2, XMLRPC, WS, J2ME, XForms, JSF) took their cue from HTML forms, and not from HTTP. I'm on the record about this as being a massive problem. I'll look forward to the day when the W3C TAG acknowledge this.
Post a Comment