- From: Cameron Heavon-Jones <cmhjones@gmail.com>
- Date: Wed, 14 Dec 2011 13:23:07 +0000
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: thibault <thibault@miximum.fr>, public-html-comments@w3.org
On 13/12/2011, at 10:03 PM, Julian Reschke wrote: > On 2011-12-13 22:41, Cameron Heavon-Jones wrote: >> >> On 13/12/2011, at 8:24 PM, Julian Reschke wrote: >> >>> On 2011-12-13 21:08, Cameron Heavon-Jones wrote: >>>> ... >>>> Yes, i understand what you mean here. It is reasonable though that these *may* be thought of\implemented as different resources, ie: >>>> >>>> http://www.example.com/index.html >>>> >>>> http://www.example.com/index.html?fragment=true >>>> >>>> Deleteing the first results in a full response, deleteing the second is a fragmented response from a fragmented version of the resource. >>>> ... >>> >>> Now you are overloading the URI. There is only one resource here, and there's no point in assigning multiple URIs. URI overloading is almost as bad as POST method overloading :-). >> >> It's a matter of interpretation. URIs are opaque so no information should be inferred from their structure. The implementation is free to define what a request will translate into in real terms, for example if i were to DELETE ./index.html would you hypothetically expect ./index.json to still be available? > > It depends. Yes, it depends on what the server wants to do, not what the client infers from introspecting a URI. I don't think there is such a thing as URI overloading, at least not in this case. The two URIs do denote different resources as they return different representations from the same request parameters. This is possible through headers and other means but different URI is at least valid for achieving different representations. > >> If a script is provided with a URI for use in DELETE-ing a resource, that is the URI it will use - without client interpretation. This is the whole point of server-driven URIs and HATEOAS. > > But then, assigning different URIs for the same or "almost the same thing" defeats things like cache invalidation. It doesn't affect cache at least, the URI's representation is *more* consistent than if you use Prefer header to initiate different representations. The fragment URI will always be returning fragments and the .html URI will be returning full html, no problems with caching. I note in Prefer specification there was some notes relating to caching but they have been removed. To go in to some further detail on why i was initially dubious of the need for a Prefer header it is due to the potential for acquiring a solution through URI modelling. This was reached as a solution for the very corner case you highlight whereby we may potentially want to serve fragments or whole html documents to the same consumer. Since a potential solution is feasible this introduces doubt, added to that i initially reviewed the Prefer header spec, albeit rather hastily, and found what i can only describe as a 'funny smell' around the ability for clients to request the type of content-representation. This was enough for me at the time to trust instincts and not investigate further, if i didn't do that on the internet my eyes would start bleeding. With your welcomed persistence, i can see how especially for some server application constructs that the Prefer header is another solution and possibly a more elegant one for some cases. I will take the time now to review the spec with the full attention it deserves and if i am unable to satisfy the initial concerns myself i will bring to the feedback discussions happening on http list. > >>>>>> ... >>>>> Please translate? >>>>> >>>>> The client tells the server to DELETE. The server has several choices about what to return. It also has several choices what formats to use for that. These are orthogonal. >>>>> >>>>> We are going in circles. >>>> >>>> As described above, the state is defined through URI. The server doesn't have a choice as there is only 1 state the resource is in. >>> >>> The URI identifies the resource. Period. >>> >>> The preference about what information to get returned upon DELETE has absolutely nothing to do with the server's or the resource's state. >> >> Yes, we're going to get back to a loop again. >> >> If i may, with further thought i don't object to Prefer header, possibly at all. You can take this as a win if you like :) >> >>> >>>>>>>> It does work with XHR and form access if the Accept header is varied. >>>>>>> >>>>>>> It may work in *some* cases by abusing the Accept header. >>>>>>> >>>>>>>> ... >>>>>>> >>>>>>> Best regards, Julian >>>>>> >>>>>> >>>>>> I really don't think i can be accused of abusing the Accept header, if anything i hold upmost conformance. I just don't vary resource state. >>>>> >>>>> I really have no idea what you refer to when you say "vary resource state". >>>> >>>> By changing the content of the representation you have transferred a different state of the resource. >>> >>> But in general, the payload returned in a DELETE response is *not* a representation of the resource identified by the URI. Actually, it's never for a succesful DELETE, because that implies that you have removed the resource. >>> >> >> It can be seen to be the 'final' state and representation of the resource, an ephemeral last glimpse if you will. > > Nope, it can't. hmmm... i don't want to get into an argument with someone of your repute especially on this subject as they never really go anywhere. we seems to have some misunderstanding in overloaded terminology and i personally don't think that either of us incorrect in our understanding although we may have parsed the spec into some nuanced mental models which is difficult to align exactly. if you really do think i have some grievous misunderstandings then please continue as i endeavour to be enlightened, but i doubt that i can provide such to yourself. > [snipped the rest] >> >> A resource is defined as a URI not as a form of content or file. > > No, a resource is *identified by* a URI, not *defined as" a URI. > > And yes, it's also not a form of content or file. Did anybody say that? > Yes, sorry for stating a basic principal. > >>>> We have reached some degree of clarity. >>> >>> I'm not convinced about that yet. >>> >>> Best regards, Julian >> >> Yeah, that's ok i more meant we seems to be getting to the same page. >> >> This is really a very puritanical discussion... >> >> Thanks >> Cam >> >> > Thanks, Cam
Received on Wednesday, 14 December 2011 16:19:06 UTC