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

131–140 of 140 posts

Re: JSON API

#131

Post by benatkin »

steveklabnik wrote: post #52
1qaz2wsx3edc wrote: post #5

Earlier quoted context omitted.

Of all people. What about hypermedia instead of rels? I feel like `ids` param is a hack, clearly the system has a group of objects, should that not be it's own collection? For instances: `GET /friends?ids=1,34,54` Could be: `GET /friends/best.json` and `best` to the system in some form, represents 1,34,54. I don't want a RESTful JSON API. I want a REST JSON API.

> What about hypermedia instead of rels? ... can you elaborate a bit more on what this means? I don't understand what you're trying to say. > I feel like `ids` param is a hack, clearly the system has a group of objects, should that not be it's own collection? I'm not 100% sure what you mean here either, but I'm reading it as "Why not use a comma rather than passing a list of GET parameters?" The answer is "I don't th…

I think 1qaz2wsx3edc means naming the key "hypermedia" instead of "rels". I don't like "rels" because it's hard to pronounce (do I say relationships or rails?) and because it it's an abbreviation. Unfortunately I can't think of something better.

When you're competing against nothing, lack of elegance is a difficult problem. The need to be elegant is stronger and you can't simply be as or more elegant than your competition.

Re: JSON API

#132

Post by [deleted] »

arianvanp wrote: post #70
bitcracker wrote: post #66

Earlier quoted context omitted.

> "could I express this as s-expressions?" Sure. "Would I want to?" Hell no. Of course it is possible to implement syntactic sugar in Lisp which supports JSON style expressions. DSLs are common in Lisp, and that actually became a weakness of Lisp (so-called "DSL hell"). The interesting thing about s-expr is that Lisp doesn't need special data conversion tools to handle them. Even control structures are expressed as s…

This is one of the most attractive things of lisp. The fact that the language has no notion of compiletime, evaltime and runtime. The user just doesnt have to care abouut it. Very powerful

[deleted]

Re: JSON API

#133

Post by nona »

tomjen3 wrote: post #80

That scheme is horrible. ? should never be part of a rest-like url and you certainly shouldn't request more than one id at a time -- the data you should show should be included in the JSON string.

I always interpreted /collection?xxx=yyy as adding constraints to a collection - that's perfectly "REST-like" (actually URIs don't really matter, but I suppose you're talking about conventions). And in that respect /collection?ids=1,2,3,4 is indeed just a subset of /collection

For a single resource you can still use /collection/1

Re: JSON API

#134

Post by nona »

wycats wrote: post #34
mahmoudimus wrote: post #24

Earlier quoted context omitted.

I second this, what's the point of not using hal?

There are several reasons I chose not to use HAL: * HAL embeds child documents recursively, while JSON API flattens the entire graph of objects at the top level. This means that if the same "people" are referenced from different kinds of objects (say, the author of both posts and comments), this format ensures that there is only a single representation of each person document in the payload. * Similarly, JSON API use…

Well, I'm guessing your second and third point could be tacked on to HAL.

I see your point with the first one, although I must say in our APIs we have rarely encountered duplication. And the recursive nature of HAL makes it really easy to generate on the server-side.

(By the way, we've introduced a sideloading convention that only when you pass along ?embedded=author,comments those sub-resources will be present under _embedded. This way the clients can easily request only what's needed.)

Re: JSON API

#135

Post by nona »

wycats wrote: post #34
mahmoudimus wrote: post #24

Earlier quoted context omitted.

I second this, what's the point of not using hal?

There are several reasons I chose not to use HAL: * HAL embeds child documents recursively, while JSON API flattens the entire graph of objects at the top level. This means that if the same "people" are referenced from different kinds of objects (say, the author of both posts and comments), this format ensures that there is only a single representation of each person document in the payload. * Similarly, JSON API use…

speaking of 200 vs 204: any way for the client to signal he's OK with just a 204 after updates/deletes?

Re: JSON API

#136

Post by westurner »

In terms of http://en.wikipedia.org/wiki/Linked_data , there are a number of standard (overlapping) URI-based schema for describing data with structured attributes:

* http://schema.org/docs/full.html

* http://schema.rdfs.org/all.json

* http://schema.rdfs.org/all.ttl (Turtle RDF Triples)

* http://rdfs.org/sioc/spec/

* http://json-ld.org/

* http://json-ld.org/spec/latest/json-ld/

* http://json-ld.org/spec/latest/json-ld-api/

* http://www.w3.org/TR/ldp/ Linked Data Platform TR defines a RESTful API standard

* http://wiki.apache.org/incubator/MarmottaProposal implements LDP 1.0 Draft and SPARQL 1.1

Re: JSON API

#137

Post by troels »

rektide wrote: post #125
troels wrote: post #106

Earlier quoted context omitted.

If I understand your question correctly, I would say that http pipelining solves that issue. It can only be used for GET requests, so there are limitations.

At least if you're going to dive into the transport layer, pick a capability that hasn't been added and then unceremoniously backed out- https://insouciant.org/tech/status-of-http-pipelining-in-chr... SPDY begins to offer some very appealing alternatives where when sending a document the transport can push all of the individual dependent documents. It really does fix things, begins pushing all the data at once, in a…

Thanks for the link - I weren't aware there were so many issues with pipelining. I have mainly used it server to server, where it seems to present less problems (not surprisingly really - I'm in much better control of the chain of components).

Re: JSON API

#139

Post by jon_moore »

wycats wrote: post #110
troels wrote: post #106

Earlier quoted context omitted.

If I understand your question correctly, I would say that http pipelining solves that issue. It can only be used for GET requests, so there are limitations.

It can only be used for GET requests, has problems in web browsers, and still requires the overhead of individual requests on the server side to construct and return many responses. In theory , things like pipelining allow you to never have to worry about compound documents. In practice, I don't know anyone who has gotten this to work well for browser clients and general-purpose frameworks when dealing with non-trivi…

N.B. Pipelining can be used for any idempotent request (so PUTs and DELETEs work too). That said, lack of broad implementation support for pipelining is still an issue. Since HTTP/2.0 is being based on SPDY, hopefully we'll see a day where this is less of an issue.

Re: JSON API

#140

Post by spopescu »

wycats wrote: post #34
mahmoudimus wrote: post #24

Earlier quoted context omitted.

I second this, what's the point of not using hal?

There are several reasons I chose not to use HAL: * HAL embeds child documents recursively, while JSON API flattens the entire graph of objects at the top level. This means that if the same "people" are referenced from different kinds of objects (say, the author of both posts and comments), this format ensures that there is only a single representation of each person document in the payload. * Similarly, JSON API use…

Wouldn't (most of) the shortcomings of HAL you mention, be overcome by Collection+JSON [0]? It seems better suited as an already existing media type that accomplishes what you try to do with JSON API.

[0] http://amundsen.com/media-types/collection/

Post reply on HN