On Feb 15, 2010, at 7:24 PM, Marc Hadley wrote:
> On Feb 15, 2010, at 11:43 AM, Jan Algermissen wrote:
>>
>>> Link headers provide a useful alternative to that of media types for certain cases of hypermedia support.
>>
>> No, I entirely do not think so because the focus on document oriented messaging is lost and I consider that essential.
>>
>> I'd only use link headers to provide hypermedia that is not very domain specific but rather general, for example
>>
>> - service documents
>> - nex,previous,up,down
>> - versions
>>
>> Occasionally this could be loosened but I'd not recommend to stuff the domain semantics in a bunch of headers.
>>
> On your blog[1] yesterday you wrote:
>
> "From a hypermedia constraint point of view it is irrelevant whether the hypermedia controls (that is links, link templates or forms) are placed inside the body or inside the HTTP headers. Placing the controls into the HTTP header can, for example, be a viable solution when you want to (or have to) use existing document formats for the body that do not provide the ability to place the controls in the body."
>
> Second thoughts perhaps ?
No, I don't see a contradiction (although I see why you see one :-)
The blog post says "From a hypermedia constraint point of view", meaning that that constraint is not violated by putting Links in headers ('fight' lurking with Markus I suspect :-)
In my response here I deliberatly wrote 'I think so' because I cannot back that by any of Roy's writings :-)
What I am still absolutely not getting is what the 'hypermedia pattern' in question is trying to solve. Without intend to insult anyone: I think it is just really confusing and feels a bit like making REST enterprisey (*feels* like; I am not saying it is)
Could it be that you guys are thinking more in terms of 'technical APIs' such as Sun Cloud while I am at the business level ("submit request for shipment" "submit ITIL incident" etc.)?
Hmm, interestingly I have worked last year on such a technical API, including things like explicit locking and what I came up with is maybe (will check) pretty comparable to what you guys are doing.
Jan
>
> Marc.
>
> [1] http://www.nordsc.com/blog/?p=376
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
-----------------------------------
Jan Algermissen, Consultant
NORD Software Consulting
Mail: algermissen_at_acm.org
Blog:
http://www.nordsc.com/blog/
Work:
http://www.nordsc.com/
-----------------------------------