[rest-practices] dumping link headers

[Bill Burke]

Sergey Beryozkin wrote:
> Hi
> 
> As far as the user's experience is concerned, what would be the difference between dealing with related pairs of custom headers
> (or complex Link header) and say some custom XMl/JSON response body representing the same information ?
> 

Depends what you're doing.  For REST Messaging, I'm using Link headers 
so I don't have to have an envelope format.  They work very nicely there.

> Using Name & Name-Type convention is simple and easy on the eye, it looks fine, but this approach is probably less likely to work well with generic clients ? Link might do better
> 

Don't care much about "easy on the eye".  I'm positioning REST (maybe 
incorrectly) as Zero client footprint, meaning, you only need an HTTP 
client lib.  Since most HTTP clients don't support link headers yet, a 
header parser would be required to be written, maintained, and 
distributed to clients.  Yeah, its only 10-20 lines of code, but it 
contradicts the user experience I'm trying to push.

At least for the RESTful interfaces I'm doing for HornetQ and TX, I 
don't see how a generic client could take advantage of the Link headers 
I'm publishing.  You could make a case that caches might like Link 
better, but for the above interfaces I'm doing, its mostly POST/PUT 
interactions.

Finally, IIRC, HTTP 1.1 states that custom headers are assumed to be 
entity headers anyways.  Not sure how that translates for generic 
clients though.

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com