Re: Byte range PATCH

>

> Could you please suggest a different phrasing?

>



Nope. I already oversimplified by neglecting to mention that a resource can also be defined by making it redirect.



Point your telescope at a random star. Is it in the star catalogue? 404, Definition Not Found. PUT a definition of it in the star catalogue -- 201, Definition Created. Surely the resource existed before anyone thought to go looking for it, and just as surely, the resource (a star) didn't come into existence by virtue of being defined?



Point your telescope at empty space. Is that space in the star catalogue? 410 Gone. Astronomers of the past catalogued it before it exploded. It might have taken a million billion years for the cache to clear, from our perspective, so to speak. That's the temporal nature of resources at work.



Same with people -- if the resource is "a person" does it cease to exist when the defined person dies? My Granddad died in 1979, but wasn't searchable on the Internet until 2008 (for writing the original bylaws of the Federation of American Scientists, when that resource was first defined by a URI responding 200 *if* the dereferencing user-agent Accepted text/html, to get wordy). My Opa died in 1989, but I doubt he'll ever be on the Internet.



When it comes to writing HTTP specs, best not conflate resource and representation, this isn't FTP where no such ambiguity exists. Goes beyond pedantry.



>

> PATCH may create resources, depending on how the media type is defined.

>



I'm aware that I've chosen a windmill to tilt at. Because it still makes no sense to me, even if I accept your "create resources" wording, for the sake of argument. I'd still rather be able to unambiguously tell from a glance at a server log, that all PATCH requests do is Update, not Create -- or Delete, which the door's wide open for if PATCH can create, ugh smh.


>

> If I’m using PATCH on a resource that doesn’t exist (404 Not Found),

> 



Try looking at 4xx responses more broadly. 404 comes the closest to saying a resource "doesn't exist" but that's hardly implied by, say, 401-3.






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

>



Not necessarily. Given that there are other tools to do the job of "Creating", I think PATCH is best left to "Updating" to avoid any ambiguities which come about when it's allowed to "context switch". I may have a resource responding 403 when dereferenced, and I may want to PATCH that entity to explain that it's Forbidden for legal reasons, and not the result of a bad password, which would be the generic 403 response from my server.



Allow PATCH to have the creation semantics inherent in PUT and POST and now there's no tool in the box to update a 403 response, etc. without ambiguity that maybe the resource context is meant to switch from "undefined" to "defined".







>

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

>



Why not use POST? Instead of overloading PATCH...



>

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

>


Helps to understand what I'm getting at if, when I say "intermediary," you don't assume I mean "cache." Being cacheable and being introspectable are two different problems.







-Eric