Re: Byte range PATCH

>

> 2. It allows segments to express HTTP semantics; for example,

> creating a resource relies on attaching a Content-Type field. You

> might even attach a Digest field indicating the expected hash of

> the final resource.

 >


 


Resources are not created. They are defined by the creation of 1+n representations which also convey the (temporal) state of the resource. My httpd uses XProc 3 as its configuration language, so it's trivial to accept a PATCH of text/plain and run it through two XSLT stylesheets, resulting in (synchronized) HTML and PDF representations.



If the client and server have the same copy of the XSLT in question, yes a Digest header can perform a CRC.



I don't grok "final resource". I do grok "final resource state" resulting from some change request.



If a PATCH request is just some plaintext, I still don't see where it makes sense to "create" anything. I do think it should be identified as text/plain, but I don't think that should be coupled to any "file format" returned by the server on GET/HEAD.



For the sake of argument, all my httpd does is filter requests and responses over a FastCGI interface to WordPress running in a BSD jail. Let's hypothetically enable PATCH support on WP. Every malformed PATCH request which makes it through to WP shall be considered a design failure.



Which has me preferring a multipart/* solution over a message/* solution, in general. Despite the parsing required, at least it's possible (and with well-known media types) to head 'em off at the pass (intermediaries, front-end), so WP only ever gets validated and sanitized requests its (hypothetical) PATCH extension understands.



Sure, your way I could use Content-Type to indicate this byte-range of plaintext is meant to update either an application/pdf or text/html representation. Sure, the client could repeat the PATCH request with another Content-Type, at the cost of synchronicity. Which while allowed, is I think a bad practice I first read about in TBL's old work that I'm too busy to dig up atm.



But it's why the world eschewed language negotiation (representations of the same resource) vs. en. es. de. fr. etc. wikipedia.org -- each variant language is a discrete resource rather than a translation (variant representations); because they're not synchronized, they have their own independent state. The definition of the resource, then, varies by language. Not the representations.



For me, hardest thing to wrap my head around in REST architecture is the resource/representation dichotomy (or Force Dyad lol). Because, thanks to caching, we can even have multiple temporal variants of the same representation, floating around out there at any given moment (even with the same media type), representing different resource states. Without changing the definition of the resource.


-Eric