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

71–80 of 140 posts

Re: JSON API

#71

Post by endgame »

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

Everyone says that, but the thing I loved most about dabbling in elisp was how much nicer things become when your text editor works at the s-expression level. Moving around and manipulating a lisp program is just plain easier than it is in nearly any other language.

Re: JSON API

#72

Post by ch0wn »

almost wrote: post #68
steveklabnik wrote: post #57

Earlier quoted context omitted.

The implementation detail of "SQL or NoSQL" should not bubble up to your API. The data store you use is totally irrelevant, that's the entire point of encapsulation.

You've just summed up what bothers me about this format.

This sounds to me as if you're not really in search of a loosely coupled hypermedia API schema, but an RPC mechanism.

Re: JSON API

#73

Post by upthedale »

pserwylo wrote: post #9

This is important. We've just been implementing a SOAP interface to our software, and have been discussing the best way to provide a JSON API using the same mechanism. The sticking point is probably that there is no standard way to define an API like there is with SOAP. One question though: I notice that the language they use if very similar to a typical RFC. Is this an RFC? and if not, why? I'm a little naive about…

I strongly suggest you have a look at OData. The latest developments define a similarly lightweight JSON data format. It does everything this proposal does, and more (methinks the things this doesn't do will likely be added as time goes, simply reinventing the wheel - e.g. see the discussions above on pagination or rich query support).

To address your issues around defining a standard JSON API - OData is itself the standard API for any OData service. All that would differ between your OData service and mine is the schema and the data inside. How you explore that schema and access that data is what OData defines.

Re: JSON API

#74

Post by akamel »

wycats wrote: post #59
akamel wrote: post #51

Earlier quoted context omitted.

The format is not identical! I was looking for a philosophical comparison between the standard (odata) and jsonapi; I am not seeing much more than a simplified response format (a transform really). Was hopping to see something more substantive in a comparison other than: 'results are returned under "d" instead of directly "posts"'. Most project need to answer the simple question of 'why?' - 'why do I as a project exi…

The references to Ember are in the introduction only and provide some historical context for the project. I believe that it's important for standards to come out of real experience, and that the context of that real experience will help others understand the goals. That's why I provided the historical background. JSON API's design is based around a smart client that wants the ability to avoid making unnecessary reque…

Thank you; That clears it up :)

Re: JSON API

#75

Post by troels »

wycats wrote: post #61
almost wrote: post #58

I think it's great that we're talking about standardising how we build RESTful JSON APIS. However I don't think this has got it quite right yet. What's the reason for the top level rel? It seems like it's just there to stop the urls from being repeated and to save space, but isn't that what gzip is for? Why complicate the data format and require all that extra logic and gzip would remove most of the redundancy before…

> What's the reason for the top level rel? It seems like it's just there to stop the urls from being repeated and to save space, but isn't that what gzip is for? It also makes it possible to cache things locally indexed on their IDs, and to form URLs that make requests for just the precise documents that aren't available locally. In order to achieve this, it's necessary to have both (1) IDs, and (2) a way to convert…

> It also makes it possible to cache things locally indexed on their IDs, and to form URLs that make requests for just the precise documents that aren't available locally. In order to achieve this, it's necessary to have both (1) IDs, and (2) a way to convert a list of IDs into a single request for all of the documents at once.

Couldn't the id column contain a canonical url then? E.g.:

    {
      "posts": {
        "id": "http://example.com/posts/1",
        "title": "Rails is Omakase",
        "rels": {
          "author": "http://example.com/people/9"
        }
      },
      "people": [{
        "id": "http://example.com/people/9",
        "name": "@d2h"
      }]
    }

Re: JSON API

#76

Post by upthedale »

wycats wrote: post #59
akamel wrote: post #51

Earlier quoted context omitted.

The format is not identical! I was looking for a philosophical comparison between the standard (odata) and jsonapi; I am not seeing much more than a simplified response format (a transform really). Was hopping to see something more substantive in a comparison other than: 'results are returned under "d" instead of directly "posts"'. Most project need to answer the simple question of 'why?' - 'why do I as a project exi…

The references to Ember are in the introduction only and provide some historical context for the project. I believe that it's important for standards to come out of real experience, and that the context of that real experience will help others understand the goals. That's why I provided the historical background. JSON API's design is based around a smart client that wants the ability to avoid making unnecessary reque…

But you haven't yet answered Akamel's question of why this exists, with comparisons to the existing standards (OData in this case).

Everything I've seen just says that this is simply a subset of OData's functionality. And the features that are being asked for by users commenting on the OP are ones already provided by the existing standard.

And what about querying the data? There have already been questions elsewhere in this thread about how this would work. OData already provides very rich query support, including document projection (returning a subset of a document) through to complex queries navigating multiple relationships (I easily could ask, through a GET query string, to return all the actors who have starred in films that belong to the comedy genre - navigating 3 collections, actors,films,genres). If queries are out of the scope, then fine, but its clear people want to query their data.

So please answer what this offers over existing standards if you want to compete.

Oh, and in response to your earlier post of what OData JSON looks like, you're much better served by linking to v4, not v2 as you did:

http://docs.oasis-open.org/odata/odata-json-format/v4.0/cspr...

That doesn't look so dissimilar.

Re: JSON API

#77

Post by draegtun »

bitcracker wrote: post #60

It amazes me how programming languages and APIs look more and more like Lisp. Modern languages copy essential features from Lisp, and JSON as one of the most popular JS libs almost look identical to Lisp s-expressions. Someday also more people will realize how useful and effective the equivalence of control structures and data really is. JSON: { "posts": { "id": "1", "title": "Rails is Omakase", "rels": { "author": 9…

Or in Rebol:

  [posts: [id: 1 title: "Rails is Omakase" rels: [author: 9 comments: [5 12 17 20]]]]
See relevant|related|interesting blog post On JSON and REBOL by Carl Sassenrath - http://www.rebol.com/cgi-bin/blog.r?view=0522

Re: JSON API

#78

Post by klibertp »

dualogy wrote: post #64
bitcracker wrote: post #60

It amazes me how programming languages and APIs look more and more like Lisp. Modern languages copy essential features from Lisp, and JSON as one of the most popular JS libs almost look identical to Lisp s-expressions. Someday also more people will realize how useful and effective the equivalence of control structures and data really is. JSON: { "posts": { "id": "1", "title": "Rails is Omakase", "rels": { "author": 9…

Yeah. Well. Also known as "in the end, everything is just an abstract syntax tree". But while a few people will always delight and excel in reading and writing everything as s-expressions, many of us will probably always find either line-breaks or different kinds of braces, brackets and little syntactic doodads make for easier and saner writing and reading -- even if the parser needs to do a bit more work. No matter…

> easier and saner writing

No. Just no. I could agree about reading, but writing is much easier with s-exps. There's just less symbols to type. And remember, you still can put newlines and indent however you want.

Re: JSON API

#79

Post by klibertp »

notimetorelax wrote: post #69
bitcracker wrote: post #60

It amazes me how programming languages and APIs look more and more like Lisp. Modern languages copy essential features from Lisp, and JSON as one of the most popular JS libs almost look identical to Lisp s-expressions. Someday also more people will realize how useful and effective the equivalence of control structures and data really is. JSON: { "posts": { "id": "1", "title": "Rails is Omakase", "rels": { "author": 9…

Or in Clojure: { "posts" { "id" "1", "title" "Rails is Omakase", "rels" { "author" 9, "comments" [ 5, 12, 17, 20 ] } } } Commas are unnecessary, I kept them for clarity.

I'm not sure I like this syntax. It's unfamiliar both to lispers and "mainstreamers". The former will be irritated with { and commas, the latter will try to insert : everywhere.

I read an interview with Rich Hickey where he said that adding these three syntax constructs reduced cognitive burden on programmers. He meant () for lists, [] for vectors and {} for hashes.

I should implement it in Racket and just see how it feels.

Re: JSON API

#80

Post by tomjen3 »

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.
Post reply on HN