5 ms·

The _links field may not be necessary. There is already an HTTP Link header proposal, and is already being used by API's like GitHub's: http://www.w3.org/Protoc

by jdp 14y ago

The _links field may not be necessary. There is already an HTTP Link header proposal, and is already being used by API's like GitHub's: http://www.w3.org/Protocols/9707-link-header.html http://www.w3.org/Protocols/9707-link-header.html From their examples, this is the equivalent representation: Link: <http://www.tld/orders/523>;rel=self, <http://www.tld/warehouse/56>;rel=warehouse, <http://www.tld/invoices/873>;rel=invoice It also allows for multiple Link headers to be sent instead of the comma-separated version.

pwpwp 14y ago
But what if you want to store the links in the content? (E.g. if you have no control over the headers a server sends.)
- danellis 14y ago
  Also, what if you want to persist the content?
jchrisa 14y ago
Problem with headers is that they basically don't exist as far as Joe beginner programmer is concerned.
- pfraze 14y ago
  Yeah, that really bothers me about web frameworks. It's particularly problematic for type negotiation, which is ignored pretty often in my experience (people tend to indicate type in the uri, using ".json," for instance).
AffableSpatula 14y ago
In my opinion, Link Headers are not a good option as the primary hypermedia of your API. They are useful for adding links to responses with a Content-Type that is not capable of expressing a link, and they are useful for protocols (http://tools.ietf.org/html/draft-nottingham-linked-cache-inv-02 http://tools.ietf.org/html/draft-nottingham-linked-cache-inv...), but they are not reliable enough for 'every day use'. HTTP Headers are frequently stripped, modified, and generally abused by intermediaries, and there is also the issue of practical upper limits on the size of the HTTP Header block. Github already use hal+json's _links convention in their latest Pull request API: http://developer.github.com/v3/pulls/ http://developer.github.com/v3/pulls/
pfraze 14y ago
I agree with this personally, because this spec is adding meta-data to the body, and headers are pretty much made for that. The practical problem is that you have to parse the link header, and it's not simple enough for common use. I think, if we want to use headers, we need to build some JS utilities for the different specs that abstract away any parsing.
- AffableSpatula 14y ago
  Already exists: https://github.com/s3u/headers.js https://github.com/s3u/headers.js There are problems with using Link headers, I think you will find less friction in practice by treating links as 'proper data' and putting them in the content body using a media type like this.
  - pfraze 14y ago
    Oh, awesome, thanks. You may be right-- HTML employs meta-data in the header, and there are good reasons for it. I like to think that I can put my meta links in the headers and content links in the json, but I may be overworking for a minor gain in simplicity.

by jdp 14y ago

pwpwp 14y ago

But what if you want to store the links in the content? (E.g. if you have no control over the headers a server sends.)

danellis 14y ago
Also, what if you want to persist the content?

jchrisa 14y ago

Problem with headers is that they basically don't exist as far as Joe beginner programmer is concerned.

pfraze 14y ago
Yeah, that really bothers me about web frameworks. It's particularly problematic for type negotiation, which is ignored pretty often in my experience (people tend to indicate type in the uri, using ".json," for instance).

AffableSpatula 14y ago

In my opinion, Link Headers are not a good option as the primary hypermedia of your API. They are useful for adding links to responses with a Content-Type that is not capable of expressing a link, and they are useful for protocols (http://tools.ietf.org/html/draft-nottingham-linked-cache-inv-02 http://tools.ietf.org/html/draft-nottingham-linked-cache-inv...), but they are not reliable enough for 'every day use'. HTTP Headers are frequently stripped, modified, and generally abused by intermediaries, and there is also the issue of practical upper limits on the size of the HTTP Header block. Github already use hal+json's _links convention in their latest Pull request API: http://developer.github.com/v3/pulls/ http://developer.github.com/v3/pulls/

pfraze 14y ago

I agree with this personally, because this spec is adding meta-data to the body, and headers are pretty much made for that. The practical problem is that you have to parse the link header, and it's not simple enough for common use. I think, if we want to use headers, we need to build some JS utilities for the different specs that abstract away any parsing.

AffableSpatula 14y ago
Already exists: https://github.com/s3u/headers.js https://github.com/s3u/headers.js There are problems with using Link headers, I think you will find less friction in practice by treating links as 'proper data' and putting them in the content body using a media type like this.
- pfraze 14y ago
  Oh, awesome, thanks. You may be right-- HTML employs meta-data in the header, and there are good reasons for it. I like to think that I can put my meta links in the headers and content links in the json, but I may be overworking for a minor gain in simplicity.