Re: Draft for Resumable Uploads

[Eric J Bowman <[e-mail]>]

Here's a better example/questions. Given the following existing-but-undefined resource (please click through):



http://example.com/xyzzy



Wouldn't sending PATCH "404 Not Found" be reasonably expected to change the 404 response body accordingly?

(no context switching)



As opposed to "creating" a resource which eventually responds 200 OK with "404 Not Found" as its message body?

(context switching)



A DARCS patch file may contain instructions for line changes, find/replace, or filesystem ops. I've created two media types, text/vnd.darcs and text/vnd.darcs-inverse. I played around with just the first using AMEND/REVERT methods, but chose to stick with PATCH and create the -inverse media type.



If sent as a PATCH request, line-change/find-replace are interpreted as amend/revert based on media type. Filesystem ops are ignored.

(no context switching)



If sent as a POST request, line-change/find-replace are ignored. Filesystem-op instructions are followed or undone, based on media type.

(context switching)



If sent as a PUT request, I don't care which vnd.darcs media type, as the patch itself is a first-class resource in DARCS. Which either overwrites (no context switching) or creates (context switching), based on method definition -- the patch is not applied, no partial PUT.



I consider that RESTful implementation of HTTP protocol, iff the PUT target comes from the server.



I would consider it bad practice (and hard to maintain) to create text/vnd.darcs-execute to allow partial PUT (overriding the method definition) by media type, or to allow PATCH to engage in context-switching (overriding separation of concerns) by media type. A patch file shouldn't be executable, just an instruction set for an executable.



I consider those REST mismatches, for subverting the Uniform Interface constraint.



My opinion is informed by DARCS being patch-centric, as opposed to the typical snapshot-centric revision control systems or UNIX diff/patch. One or more "context" resources must first be defined, in order for any patch to have meaning. A find/replace foo/bar patch may be applied to any context. A client can derive any snapshot from a context plus one or more patches; no server-derived snapshot URI needed. Roll your own repo and define that snapshot as a context, perhaps assigning it a URI. Just a stored procedure.



DARCS is just recursive lambda calculus expressed as Haskell functions, grok that at the risk of hating git. ;) It almost solves for distributed resumable uploads: conflict management is the cutting edge of DARCS development.



Restricting PATCH to just mean "patch" and disallowing partial PUT simplifies the security scheme to "user/group by protocol method, per naming authority" copacetic with peer-to-peer distributed-repository operations. Anyone can GET/HEAD/OPTIONS/PATCH. Operators can approve (apply) a PATCH. Creators may define contexts. Etc. This is significantly harder to implement if PUT or PATCH semantics vary by media type!



Wouldn't application-layer concerns bleeding through to the protocol layer like that, indicate a layered-system mismatch? Abiding by the uniform interface constraint would preclude the layering violation. I see value in acknowledging REST mismatches even if it changes nothing (cookies still won't die even with the UI pollution legislatively mandated for using them). Serves to inform implementers who care about getting the most REST benefits HTTP has to offer, of BCP expressed as what not to do.



-Eric