Don't really like Set-Link for most situations
Bill Burke
entity header and should be related to the representation you are
transmitting. When set with a request it is metadata about the
representation you are transmitting. When set with a response it is
metadata about the representation the client will receive. So, IMO, no
need for Set-Link.
Set-Link would require semantics. For example, what does Set-Link mean
in the Post-Create-Forward algorithm? It would mean something different
with a PUT. That's why, IMO, Link alone is good enough for most
scenarios. Where I think Set-Link would be useful would be for HTTP
Method LINK and UNLINK tunneling.
Bill
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
Sam Johnston
Where I think Set-Link would be useful would be for HTTP Method LINK and UNLINK tunneling.
That's basically where it came from... creating new HTTP verbs is risky business but headers (especially those over SSL) are safe. Using Link: for both setting and getting makes more sense at first, but the status quo (cookies) use Set-* and there are additional concerns for setting (such as the ability to delete links by passing the 'discard' attribute).
Sam
Bill Burke
You need to remember that cookies are not entity headers. They are not
metadata about the entity enclosed in the message body. The Link header
is an entity header.
Again, Set-Link does not work in many scenarios because the semantics of
its application differ between link relationships. For example:
POST /factory
Set-Link: <...>, rel="alternative"
Now is POST /factory a Post-Redirect-GET pattern? Or something else?
Not all posts are the Post-redirect-Get pattern. Following me now?
Plus LINK/UNLINK method invocations are going to be very rare in most
applications, but transmitting link headers with a post-redirect-get
pattern will be very common, IMO.
Sam Johnston
You need to remember that cookies are not entity headers. They are not metadata about the entity enclosed in the message body. The Link header is an entity header.
Again, Set-Link does not work in many scenarios because the semantics of its application differ between link relationships. For example:
POST /factory
Set-Link: <...>, rel="alternative"
Sorry to be a bit slow tonight (it is 2am and I have hardly slept this week[end] with moving) but are you saying that there is ambiguity as to whether the header applies to the /factory resource or a new resource to be created by the POST?
Now is POST /factory a Post-Redirect-GET pattern? Or something else? Not all posts are the Post-redirect-Get pattern. Following me now?
Perhaps, but I'm not sure it matters except for the potential ambiguity above.
Plus LINK/UNLINK method invocations are going to be very rare in most applications, but transmitting link headers with a post-redirect-get pattern will be very common, IMO.
Problem is that while LINK/UNLINK were originally defined they were subsequently dropped. Mark hasn't catered for the setting of Link: headers and presumably assumes the server already knows what they should be (thereby leaving it up to non-standard RPC APIs to update them).
So in your opinion can we drop the Set-* and just use Link: on both sets & gets or do we need a first class HTTP verb?
Sam
Bill Burke
Sam Johnston wrote:
> On Tue, Oct 20, 2009 at 12:44 AM, Bill Burke <bbu...@redhat.com
> <mailto:bbu...@redhat.com>> wrote:
>
> You need to remember that cookies are not entity headers. They are
> not metadata about the entity enclosed in the message body. The
> Link header is an entity header.
>
> Again, Set-Link does not work in many scenarios because the
> semantics of its application differ between link relationships. For
> example:
>
> POST /factory
> Set-Link: <...>, rel="alternative"
>
>
> Sorry to be a bit slow tonight (it is 2am and I have hardly slept this
> week[end] with moving) but are you saying that there is ambiguity as to
> whether the header applies to the /factory resource or a new resource to
> be created by the POST?
>
>
> Now is POST /factory a Post-Redirect-GET pattern? Or something
> else? Not all posts are the Post-redirect-Get pattern. Following me
> now?
>
>
> Perhaps, but I'm not sure it matters except for the potential ambiguity
> above.
>
Yes, and this would be a common ambiguity problem.
>
> Plus LINK/UNLINK method invocations are going to be very rare in
> most applications, but transmitting link headers with a
> post-redirect-get pattern will be very common, IMO.
>
>
> Problem is that while LINK/UNLINK were originally defined they were
> subsequently dropped. Mark hasn't catered for the setting of Link:
> headers and presumably assumes the server already knows what they should
> be (thereby leaving it up to non-standard RPC APIs to update them).
>
I guess I could ask him.
> So in your opinion can we drop the Set-* and just use Link: on both sets
> & gets or do we need a first class HTTP verb?
>
My opinion is that the Link header is in the same class as Content-Type,
Content-Encoding, etc... it is a description of the entity contained in
the HTTP message....whether the message is a request or a response.
Sam Johnston
Yes, and this would be a common ambiguity problem.Perhaps, but I'm not sure it matters except for the potential ambiguity above.
Hmm... that may be true... and you think the only way to solve it (aside from writing rules) is "new" HTTP verb(s)?
I guess I could ask him.
Plus LINK/UNLINK method invocations are going to be very rare in
most applications, but transmitting link headers with a
post-redirect-get pattern will be very common, IMO.
Problem is that while LINK/UNLINK were originally defined they were subsequently dropped. Mark hasn't catered for the setting of Link: headers and presumably assumes the server already knows what they should be (thereby leaving it up to non-standard RPC APIs to update them).
Please.
My opinion is that the Link header is in the same class as Content-Type, Content-Encoding, etc... it is a description of the entity contained in the HTTP message....whether the message is a request or a response.
So in your opinion can we drop the Set-* and just use Link: on both sets & gets or do we need a first class HTTP verb?
Yes, it certainly refers to the payload but then most headers do - they are metadata after all. What's your thoughts on arbitrary metadata in the headers then, ala Microsoft Azure's get and set functions? This is something else I'm pushing for OCCI with a view to leaving the entity-body "8-bit clean" for existing standard formats like OVF.
Sam
Bill Burke
Sam Johnston wrote:
> On Tue, Oct 20, 2009 at 5:18 AM, Bill Burke <bbu...@redhat.com
> <mailto:bbu...@redhat.com>> wrote:
>
>
> Perhaps, but I'm not sure it matters except for the potential
> ambiguity above.
>
>
>
> Yes, and this would be a common ambiguity problem.
>
>
> Hmm... that may be true... and you think the only way to solve it (aside
> from writing rules) is "new" HTTP verb(s)?
>
No, i'm saying there is no ambiguity when just Link is used in request
headers as it is describing the message body. Something like a new HTTP
verb (or a tunnel like Set-Link) would be required if a client *just*
wants to set or unset a link. Which, IMO, will be very rare.
>
>
>
> Plus LINK/UNLINK method invocations are going to be very rare in
> most applications, but transmitting link headers with a
> post-redirect-get pattern will be very common, IMO.
>
>
> Problem is that while LINK/UNLINK were originally defined they
> were subsequently dropped. Mark hasn't catered for the setting
> of Link: headers and presumably assumes the server already knows
> what they should be (thereby leaving it up to non-standard RPC
> APIs to update them).
>
>
> I guess I could ask him.
>
>
> Please.
>
>
>
> So in your opinion can we drop the Set-* and just use Link: on
> both sets & gets or do we need a first class HTTP verb?
>
>
> My opinion is that the Link header is in the same class as
> Content-Type, Content-Encoding, etc... it is a description of the
> entity contained in the HTTP message....whether the message is a
> request or a response.
>
>
> Yes, it certainly refers to the payload but then most headers do
Actually they don't (think Set-Cookie/Cookie, Cache-Control, etc...).
There are 3 classes of headers if you look at the HTTP specification.
By default, any unstandard header is assumed to be an entity header.
- they
> are metadata after all. What's your thoughts on arbitrary metadata in
> the headers then, ala Microsoft Azure's get
> <http://msdn.microsoft.com/en-us/library/dd179350.aspx> and set
> <http://msdn.microsoft.com/en-us/library/dd179414.aspx> functions? This
> is something else I'm pushing for OCCI with a view to leaving the
> entity-body "8-bit clean" for existing standard formats like OVF.
>
I'll take a look.
Sam Johnston
No, i'm saying there is no ambiguity when just Link is used in request headers as it is describing the message body. Something like a new HTTP verb (or a tunnel like Set-Link) would be required if a client *just* wants to set or unset a link. Which, IMO, will be very rare.
I think this is Mark's assumption too, but if I want to use HTTP & Link: as a meta-model (I do) then creating links between resources is a reasonably common activity. Anyway if you need to do it once you need to do it a million times.
Actually they don't (think Set-Cookie/Cookie, Cache-Control, etc...). There are 3 classes of headers if you look at the HTTP specification. By default, any unstandard header is assumed to be an entity header.Yes, it certainly refers to the payload but then most headers do
Ok, so that's what I want anyway.
- they
are metadata after all. What's your thoughts on arbitrary metadata in the headers then, ala Microsoft Azure's get <http://msdn.microsoft.com/en-us/library/dd179350.aspx> and set <http://msdn.microsoft.com/en-us/library/dd179414.aspx> functions? This is something else I'm pushing for OCCI with a view to leaving the entity-body "8-bit clean" for existing standard formats like OVF.
I'll take a look.
Thanks,
Sam