Re: Byte range PATCH

> On Aug 5, 2022, at 11:51, Eric J Bowman <mellowmutt@zoho.com> wrote:
> 
> >
> > 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.

Could you please suggest a different phrasing?

Despite the technical definition of a resource, “create” is still an unambiguous term (it’s relative to the current moment in time), and appropriate here: What’s important is that previously the server would return 404 (Not Found) and now it returns 200 (OK). And presumably, the operation that caused this change responded 201 (Created).

> 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.

“Final resource state” is a good suggestion.

> 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.

PATCH may create resources, depending on how the media type is defined. If I’m using PATCH on a resource that doesn’t exist (404 Not Found), then there’s only one useful thing that that request could possibly be asking for (i.e. create the resource). There’s also conditional request headers to require (If-None-Match: *) or prohibit (If-Match: *) this creation behavior.

If this weren’t able to create the resource, I would have to use a PUT to create it, and there would be no way to indicate, during this operation, the “intended final length” of the resource.

> 
> 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.

It is also possible to validate message/byterange: It’s identical to an HTTP message without the "start-line", and you can validate it with a regular expression (which is impossible with multipart/*).

> 
> 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.

I’m not sure what the practical effect of this is; PATCH and caching both have well-defined semantics that play nicely with each other. (Generally a client knows when it’s getting a cached copy instead of an origin response, and conditional requests can avoid lost writes if the client’s cached copy is outdated.)

Thanks,

Austin.