Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JSON API

jsonapi.org

Post reply on HN
Print view View original

41–50 of 140 posts

Re: JSON API

#41

Post by CiaranMcNulty »

mahmoudimus wrote: post #37
wycats wrote: post #28

Earlier quoted context omitted.

The `PATCH` mechanism is an HTTP verb (RFC 5789: http://tools.ietf.org/html/rfc5789 ) using a standard patching mechanism (RFC 6902: http://tools.ietf.org/html/rfc6902 ). Both are RFCs that seemed like good foundations to build on.

Ah, I hadn't heard of RFC6902. I'll give it a read. I'm still of the opinion that it might be overkill to use only replace from that RFC when you can just PATCH the actual field to change. Is there some bit of wisdom or experience that I'm missing?

It's hard to do key removal that way, you end up reasserting all of the other fields in that subdocument, whose values may have changed since your last retrieval.

There's also some value in the patch format looking somewhat different to the main format, to avoid confusion.

Re: JSON API

#42

Post by akamel »

wycats wrote: post #36
akamel wrote: post #33

this protocol seems to be a solution for ember; there are already other very similar protocols; why is this called jsonapi.org and not emberjsonapi.org? as noted in other comments, there is JSON HAL; there is also OData (you might not appreciate that it is an ms initiative, but its pretty well established and has many providers) http://www.odata.org/libraries/

JSON HAL is an document format only; it does not formalize a protocol. JSON API is a solution for any "smart" client that is capable of caching documents and intelligently limiting subsequent requests. In general, I believe it will be broadly useful for JavaScript frameworks (and native libraries) that want to abstract the nitty gritty of how a document comes over the wire from its "model" representation.

got it; so how would you compare it to odata?

Re: JSON API

#43

Post by wycats »

akamel wrote: post #42
wycats wrote: post #36

Earlier quoted context omitted.

JSON HAL is an document format only; it does not formalize a protocol. JSON API is a solution for any "smart" client that is capable of caching documents and intelligently limiting subsequent requests. In general, I believe it will be broadly useful for JavaScript frameworks (and native libraries) that want to abstract the nitty gritty of how a document comes over the wire from its "model" representation.

got it; so how would you compare it to odata?

Take a look: http://www.odata.org/documentation/odata-v2-documentation/js...

Re: JSON API

#44

Post by wycats »

jeffamcgee wrote: post #35

The twitter API originally used pages, but they realized it was a mistake: https://dev.twitter.com/docs/working-with-timelines . The way the facebook API does it is a lot more sane: http://developers.facebook.com/docs/reference/api/pagination... . I think that you should specify the format for cursor based paging of resource collections. One way to do it would be to require a url to get more results: { "posts": [...]…

Agreed. If I standardize pagination, I'll be using a "since" token, not pages (this is actually something Ember Data already supports, but weakly).

Re: JSON API

#45

Post by mahmoudimus »

CiaranMcNulty wrote: post #41
mahmoudimus wrote: post #37

Earlier quoted context omitted.

Ah, I hadn't heard of RFC6902. I'll give it a read. I'm still of the opinion that it might be overkill to use only replace from that RFC when you can just PATCH the actual field to change. Is there some bit of wisdom or experience that I'm missing?

It's hard to do key removal that way, you end up reasserting all of the other fields in that subdocument, whose values may have changed since your last retrieval. There's also some value in the patch format looking somewhat different to the main format, to avoid confusion.

ah, key removal is indeed much easier this way.

Re: JSON API

#46

Post by mahmoudimus »

wycats wrote: post #40
mahmoudimus wrote: post #37

Earlier quoted context omitted.

Ah, I hadn't heard of RFC6902. I'll give it a read. I'm still of the opinion that it might be overkill to use only replace from that RFC when you can just PATCH the actual field to change. Is there some bit of wisdom or experience that I'm missing?

The main reason was to unify patches to attributes with patches to relationships, which do require richer semantics. It also makes it really easy to add a compound PATCH (updates to posts/1/title, posts/1/rels/author, posts/2/body, etc. all at the same time) in a single format. Once I bought into JSON Patch for the rest of this stuff, I figured I may as well use it for attributes :)

Interesting, how can I get more involved with how this is going to shape up?

Re: JSON API

#49

Post by steveklabnik »

mahmoudimus wrote: post #45
CiaranMcNulty wrote: post #41

Earlier quoted context omitted.

It's hard to do key removal that way, you end up reasserting all of the other fields in that subdocument, whose values may have changed since your last retrieval. There's also some value in the patch format looking somewhat different to the main format, to avoid confusion.

ah, key removal is indeed much easier this way.

The biggest advantage, though, is the same as any reason why you follow a standard: JSON-patch and the PATCH verb are understood by everyone, and so re-using them to take advantage of generality is better than inventing your own special take on updating JSON documents.
Post reply on HN