JSON API

http://jsonapi.org/

by steveklabnik • 13 years ago

227 135 13 years ago

jsonapi.org

rcsorensen2• 13 years ago

It's great to see this laid out in a single place.

Couple of things that might be nice to see here:

* Pagination concerns

You call out "meta: meta-information about a resource, such as pagination", but that doesn't say whether things are 0/1 based, what the names of the values for per-page are, how to indicate length of the underlying collection, etc.

* Search concerns

I don't know whether this is an area that has best practices yet, but having it said and decided on something called "jsonapi.org" could save many people many hours of pain in the future.

* Elective compound documents

Bit more of a reach, but there have been a bunch of times I wanted to say "this resource, and these relations of it, and those relations of those". And in some cases partial documents (id and name alone) of those tertiary relations.

steveklabnik20• 13 years ago

I am literally sitting on a plane right now, but as soon as I get off, will be registering this type with IANA. So that helps #2.

#3 will be do-able I think. I'm interested in this too.

#1 is something that needs a good answer, yes. I THINK it's out of the scope of this, as there are already registered REL values that handle this, but we should clarify.

I will be happy to answer anyone else's questions after I land, it's time to turn off electronic devices.

1qaz2wsx3edc5• 13 years ago

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.

rcsorensen2• 13 years ago

I worded #2 really, really poorly.

I'd love to see a spec for how to search a collection against an API that is jsonapi compliant. Different folks are all over the place here.

The base URL for search is different for different API producers. I like

  GET /teams?homecity=los+angeles

but have also seen things like

  GET /search/teams?homecity=los+angeles

  GET /teams/search?homecity=los+angeles

How to specify mildly complex search parameters is also unclear in the world. For referenced objects "/teams?homecity.state=ca" seems to fit with the style used for URL templates.

For bounded queries, should it be mongodb style?

  GET /teams?homecity.population.$lt=100000&homecity.population.$gt=100

And since we're talking about searches and pagination, do we need to specify a parameter for ordering results?

  GET /teams?wins.$gt=3&$order=homecity.population.$desc

tericho• 13 years ago

This is fantastic, looking forward to promoting it for widespread adoption once it's stable.

calebio3• 13 years ago

Is there any reason the top level objects are represented as an array of objects vs an object keyed on ID? Sure the ID would have to then be a string, but I feel that keying it on ID with direct lookup far outweighs having to search for your item each time.

I feel that if you have an author with many comments:

{ authors: { '1': { id: '1', comments: [1, 2] } }, comments: { '1': {}, '2': {} } }

it would be easier to say results['comments']['1'] instead of performing some type of search across them each time.

oinksoft• 13 years ago

Ordering. The ECMAScript standard does not specify property enumeration order.

alexkcd4• 13 years ago

The related documents are indexed by id from the primary document, so ordering doesn't matter, and it makes sense to use a format suggested by calebio, as it's both more efficient and terse. However, the primary document and other nested entities which require ordering should return an array of objects.

Edit: clarification

pserwylo• 13 years ago

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 the process for submitting them and getting them accepted, but it would be great if this ended up as an official RFC that could be referred to just like SOAP/WSDL.

mahmud• 13 years ago

RFC vocabulary, and indeed, the entire format is perfect for writing specifications. And software people have become good at reading them. So it's common to see it outside IETF standards and docs.

plorkyeran• 13 years ago

I find the MUST/SHOULD/MAY (NOT) wording so natural and obvious that I end up using it pretty much anywhere it's applicable, and I assume I'm not alone in that. I do sometimes edit out the caps, though.

steveklabnik20• 13 years ago

1) I'm assuming this is Poe's Law trolling about SOAP. If not, then I apologize, but I'm not sure I can assume good faith on this one.

If you're not, then this is significantly different than SOAP, so no, this isn't what you're looking for.

This is not an RFC. It may eventually become an internet-draft and then (hopefully) an RFC.

upthedale2• 13 years ago

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.

coderzach• 13 years ago

Why not use JSON HAL?

http://stateless.co/hal_specification.html

mahmoudimus6• 13 years ago

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

wycats22• 13 years ago

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 uses IDs for linkage, which makes it possible to cache documents from compound responses and then limit subsequent requests to only the documents that aren't already present locally. If you're lucky, this can even completely eliminate HTTP requests.

* HAL is a serialization format, but says nothing about how to update documents. JSON API thinks through how to update existing records (leaning on PATCH and JSON Patch), and how those updates interact with compound documents returned from GET requests. It also describes how to create and delete documents, and what 200 and 204 responses from those updates mean.

In short, JSON API is an attempt to formalize similar ad hoc client-server interfaces that use JSON as an interchange format. It is specifically focused around using those APIs with a smart client that knows how to cache documents it has already seen and avoid asking for them again.

It is extracted from a real-world library already used by a number of projects, which has informed both the request/response aspects (absent from HAL) and the interchange format itself.

eranation• 13 years ago

This is great, but I can't seem to be able to find the NoSQL flavored support. Seems great for relational style data models, but (I'm sure I'm missing something) I didn't see support for full nested document models. Did I entirely miss the point?

steveklabnik20• 13 years ago

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.

almost5• 13 years ago

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

mahmoudimus6• 13 years ago

The PATCH mechanisms seem like RPC to me. Having an operation that is passed in the payload, i.e. "replace", is awkward.

Why can't you just PATCH a resource?

    PATCH /resource

    {
        "src": "newvalue.png"
    }

wycats22• 13 years ago

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.

mahmoudimus6• 13 years ago

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?

akamel5• 13 years ago

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/

wycats22• 13 years ago

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.

akamel5• 13 years ago

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

sandstrom• 13 years ago

I think this is an excellent proposal. My only comment would be to clarify, next to the references to Ember, that this isn't exclusive to Ember (it is kind of obvious given the name/domain, but I think it may trip some people up).

jeffamcgee• 13 years ago

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": [...]
      "meta": {
        "next":"/posts/search?q=baseball&after=1234"
      }
    }

Another option would be for it to be a key/value pair that must be added to the url:

    {
      "posts": [...]
      "meta": {
        "next":"after=1234"
      }
    }

Either way, rest clients should treat it as a meaningless string.

wycats22• 13 years ago

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

steveklabnik20• 13 years ago

Currently, we don't say anything about searching. That's really an application-level concern, not something that needs to be in this spec.

(So you'd define your own rels and use them, doesn't affect this level of abstraction.)

almost5• 13 years ago

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 transmission anyway?

Also the name is a bit of an annoying land grab. It'll make it hard to talk about JSON APIs without getting them confused with JSON APIs that specifically use "JSON API".

Lastly, it really seems based on a rails active record style data store, it's assuming ids are the most important thing and that links are all relations that point to other objects within the system. Proper hyperlinks and point anywhere and can link together disperate systems which don't necessarily all use the exact same formats.

wycats22• 13 years ago

> 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 a list of IDs into a single request for all of the documents at once.

> Also the name is a bit of an annoying land grab

HAL is "The Hypertext Application Language". In general, people tend to be using generic names for these things, so I chose an available, generic name.

> Lastly, it really seems based on a rails active record style data store, it's assuming ids are the most important thing and that links are all relations that point to other objects within the system

I reviewed a large number of server-side solutions (Firebase, Parse, CouchDB, Django, Rails) and they all had the concept of an ID for the document. As I said above, this ID is useful to keep track of which documents have already been cached locally, and how to formulate a URL that makes a request for just the missing URLs. I don't consider this solution to be particularly tied to ActiveRecord.

Less importantly, it is also more convenient to cache documents on the server using their IDs (or slugs, or whatever the storage wants to use), and allow a top-level configuration to define how to generate URLs. This allows server-side solutions to serialize and cache documents without having to be plugged into the router architecture, but enforces a URL-centric view once the HTTP response is built.

almost5• 13 years ago

The thing is that "JSON API" was not available, it's already in common use to describe APIs that use JSON. "HAL" is totally not the same, it's clearly a name chosen to not conflict with existing terminology.

The proper layer for caching is HTTP, do we really want to end up with duplicated overlapping functionality between the layers? I see you have an application specific need for a certain thing but I don't think it generalises enough.

A few other things I noticed:

- There's no name spaceing of your special properties, they're just mixed up with the domain-specific properties. So I can't have a property of my object named "rel" and worse still you can't ever add features to the spec without breaking backwards compatibility.

- No type information in items, which kind of breaks automatic caching.

- Multiple entities returned for a URL with no indication as to which is the main one represented by that URL and which are just extra associated ones.

troels5• 13 years ago

> 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"
      }]
    }

rektide3• 13 years ago

"HAL" describes something specific and has uniqueness to it- seriously dude, pick a name that's something short of "this is the internet," even if it is doing something core such as defining interlinked data in 21c.

How's that, Interlinked Json, IJ? Relational Json? Seriously, pick something that's not going to muddy the highest level of namespace we swim in wycats.

bitcracker3• 13 years ago

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, "comments": [ 5, 12, 17, 20 ] } } }

LISP: (posts (id 1) (title "Rails is Omakase") (rels (author 9) (comments (5 12 17 20))))

dualogy• 13 years ago

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 what kind of code I'm looking at: "could I express this as s-expressions?" Sure. "Would I want to?" Hell no.

bitcracker3• 13 years ago

> "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-expr, and they can be created and modified dynamically which means that even code can be exchanged at runtime on the fly.

klibertp2• 13 years ago

> 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.

cpa• 13 years ago

I think it's more about the tree data structure than about LISP. LISP just makes the underlying data structure obvious, but as you implied we are far from seeing any LISP-semantics in JS(ON).

notimetorelax2• 13 years ago

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.

klibertp2• 13 years ago

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.

draegtun2• 13 years ago

Wouldn't it be better to use keywords here?:

  { :posts { :id 1 :title "Rails is Omakase" :rels { :author 9 :comments [5 12 17 20] }}}

draegtun2• 13 years ago

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

hnriot• 13 years ago

It's JavaScript, that's the syntax notation for JavaScript objects. Sure it resembles lisp and python, but that's just how languages come to be. If I were to invent a new language, if likely use {} for dictionaries and [] for lists too.

Lisp is harder to read than JavaScript because it doesn't disambiguation between lists and dictionaries in a clear way like js and python do.

orijing• 13 years ago

Relevant:

http://paulgraham.com/icad.html

rektide3• 13 years ago

S-exps are "just" data structures, so that you are reading s-exps when you see other data-structures presented is no surprise.

This is easy to identify: nearly all json is just atoms thought- very few json definitions encode any kind of machine-works or program-code.

So, to put it another way: it amazes you how all Lisp looks like data structures. And hopefully I've helped let you know why you are so amazed here, thanks for reading.

ch0wn3• 13 years ago

I read a lot of RFCs and drafts for media types lately and what strikes me reading this spec is the very liberal use of MUST which seems to me like an unnecessary violation of the robustness principle, that Jon Postel introduced first in RFC761 (TCP). Mike Amundsen describes in his book 'Building Hypermedia APIs […]':

    Media type designers should keep Postel in mind. Designers can make
    supporting the Robustness Principle easier for implementor by keeping the
    number of MUST elements in the compliance profile to a minimum. The fewer
    MUST elements implementors need to support, the more likely it is that they
    will be able to craft compliant representations using that media type.

tomjen33• 13 years ago

Postels law is the worst kind law ever made in IT. Take a look at how many security bugs that comes from being 'accepting' of bad HTML/CSS/Javacscrip/PDF files.

Be a nazi in what you accept, fail loudly and early enough and there will be no problem for the user to correct his error - it is only when you 50000 php pages full of echo statements that you can't change. If it had complained when he made the first, he wouldn't be in that situation now.

And don't tell me that nobody would use it then. C++, C# and Java are the top most used languages and they are all anal-retentive.

steveklabnik20• 13 years ago

Yes, I want to reduce some of the MUSTs, or at least justify them more strongly. Right now they're based on what our running code absolutely needs.

wycats22• 13 years ago

Indeed. In my experience, looser requirements in this kind of thing just leads to tears on the part of client and server implementations. I'll happily reduce some of the MUSTs to SHOULDs or MAYs if it makes sense for the communication channel to consider them optional.

tomjen33• 13 years ago

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.

stilkov4• 13 years ago

> ? should never be part of a rest-like url

Why would you say something like that? There's no basis for that at all. From a REST POV, URIs are just opaque identifiers, the characters they're made up from don't matter a bit.

nona3• 13 years ago

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

the1• 13 years ago

please at least include referer link in the response

steveklabnik20• 13 years ago

That'd normally be included in headers, it's not really relevant to a media type.

southpolesteve• 13 years ago

What timing! I just released the first version of a rails engine that automatically builds APIs to match Ember Data. It also uses active model serializers. Check it out here: https://github.com/southpolesteve/api_engine

I would love to get some feedback on the initial version. I will definitely be implementing more of the OP's spec this weekend.

stilkov4• 13 years ago

First, I think it's awesome that you guys are documenting this for others to re-use, whether it ends up being the one true format or not. Having options to choose from is doubtlessly good.

Some thoughts:

1. I'm not sure about the name. There will definitely many JSON APIs that don't use (your) JSON API for a long time, even if this becomes hugely popular. I don't see how this will not lead to avoidable confusion in the future. Given that it's very document-centric, why not use something like "JSON Doc API" or similar?

2. In the ID approach, why are the base URIs the client needs to know about not always discoverable, e.g. using standard link relations? Or phrased differently, why would I ever not want to use the "URL Template Shorthands" approach mentioned later?

3. Why use application/json and not something more specific? I can see some reasons, but would be interested in yours.

4. On creation, if I accept the pain of generating an ID on the client and can construct the URI using the template, why can't I use PUT instead of POST?

5. If I use a POST to create something, why don't I get a 201 Created with a Location header?

6. I'd suggest to upgrade the "MAY" for caching to a "SHOULD".

/edited to match @steveklabnik's numbers

steveklabnik20• 13 years ago

1. All media types are 'document centric.' And real REST APIs serve up documents. So seems fine to me. Also, IANA does not have a 'api+json' type registered (until I did so last night), so the name isn't taken.

2. If you're transitioning _to_ this kind from some sort of older kind. Remember, this is extracted from real, working software; it's not some sort of thing we imagined up. Not everyone is super on the hypermedia bandwagon yet, and some will need to transition kind of slowly.

3. I filed for 'appplication/vnd.api+json' yesterday, and so we'll be changing the document as soon as the IANA gets back to me.

4. You could, in theory. Allowing PUT seems fine, it just doesn't often seem to be the case, so we didn't include it. I wouldn't mind having that in there.

5. You should be, this is an oversight.

6. That's very possible.

stilkov4• 13 years ago

> 1. All media types are 'document centric.'

What I meant is that this is a particular kind of backend API, a very "model-centric" one. Nothing wrong with that, I just don't think this is the one and only kind and thus should take on the generic name.

> 2. If you're transitioning _to_ this kind from some sort of older kind.

Understood. Maybe an approach is to allow for this to specified optionally, with the fallback of being hard-coded if it's not present?

wycats22• 13 years ago

> I'm not sure about the name

Good feedback. Many people have said this, and I'm thinking about an alternative.

> Or phrased differently, why would I ever not want to use the "URL Template Shorthands" approach mentioned later?

You can think of the ID-based approach as just coming with a set of default URL templates in a top-level rel. The primary reason I included it (and I considered not including it), is that it may be easier for servers, when getting started, to adhere to both strict URL naming and skip generating URLs in the JSON serialization layer of their application. I'm working on some tooling for Rails that will pretty much eliminate these considerations, but I weighed ease of server-implementation when I built this. Again, don't think of the ID form as being URL-less, think of it as coming with a default, easy to implement URL template.

> Why use application/json and not something more specific? I can see some reasons, but would be interested in yours.

Two reasons: (1) Many existing clients and servers already support easy generation of JSON requests and JSON responses. (2) I haven't yet registered an alternative MIME type.

> On creation, if I accept the pain of generating an ID on the client and can construct the URI using the template, why can't I use PUT instead of POST?

Good point. That seems fine.

> If I use a POST to create something, why don't I get a 201 Created with a Location header?

Also good point, and an embarrassing oversight on my part. That should be how it works.

> I'd suggest to upgrade the "MAY" for caching to a "SHOULD".

Hmm. You think a server SHOULD use HTTP caching? RFC terminology is pretty dodgy, but caching really seems more like an optional feature ("One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item") than a strong recommendation ("This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course").

Thanks for all the feedback. It was really valuable.

stilkov4• 13 years ago

> You can think of the ID-based approach as just coming with a set of default URL templates in a top-level rel.

Then I'd be perfectly happy. But why is the paragraph that mentions exactly this ("... The top-level of a JSON API document MAY have the following keys") in the "URL-Based JSON API" section?

> You think a server SHOULD use HTTP caching?

No, you're probably right - a SHOULD is too strong. I guess my reaction was more negative to the "MAY" in your text about caching than anything else. The caching section (which is currently in the writing document?) doesn't seem to actually add much value beyond what HTTP says anyway. Maybe dropping it is the easiest path?

steveklabnik20• 13 years ago

I've filed an Issue for you about PUT: https://github.com/json-api/json-api/issues/4

gavinjoyce2• 13 years ago

A few additions that I'd like to see:

* Standardized paging

* Optional side-loading - GET /albums.json?include=artists,songs

* Multiple meta elements - so we'd have "albums_meta", "artists_meta" and "songs_meta" in the example above. This allows us to include 'has_n' relationship paging data.

wycats22• 13 years ago

Thanks for the feedback :)

Standardized paging seems to come up a lot, so it seems like a good thing to add once the core spec stabilizes. Optional sideloading also has come up a few times, and seems easy to add as a MAY in the spec. I need to flesh out the meta stuff in general, and the ability to have "meta anywhere" as well as top-level metas is coming.

gavinjoyce2• 13 years ago

Nice, thanks. I've been building an alternative to ActiveModel::Serializers which provides these features.

https://github.com/RestPack/restpack-serializer

In the light of your proposals, I'll either implement JSON API or switch back to AM:Serializers. Side-loading, paging and Ember Data compatibility are my main goals.

steveklabnik20• 13 years ago

I've filed an issue for you about sideloading https://github.com/json-api/json-api/issues/5

dacort• 13 years ago

I was a little confused that an "author" rel would be retrieved from a "people" resource. Is there a way to define that author's are people other than the client knowing this?

steveklabnik20• 13 years ago

1. I think that this is a typo

2. This spec is for protocol-level semantics, you define your application semantics with a profile link in the meta section.

westurner• 13 years ago

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

jorisw• 13 years ago

Needs an introduction paragraph. E.g. what the purpose is of the site.

JSON API

Related Stories