121–130 of 140 posts
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?
2. This spec is for protocol-level semantics, you define your application semantics with a profile link in the meta section.
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…
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.
Earlier quoted context omitted.
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 hyperme…
> 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…
> with the fallback of being hard-coded if it's not present?
See above for some other good stuff about the IDs that wycats knew that I wasn't as current on.
Earlier quoted context omitted.
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.
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.
Earlier quoted context omitted.
How would you combine multiple authors into a single request? With IDs + a template, you can form a single request for all of the "people" you don't have yet. If you use URLs as IDs, which is one of the primary goals here.
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.
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 glorious resource-oriented fashion. That said, I would also enjoy a spec that does resource-description of subresources so we can send linked data around without having to have every piece of data be an endpoint.
That said, the immediate follow on question arises- now that we're sending sub-resources, can we get the most important agent to understand and grok our sub-resources- can the browser follow our subresourcing and those subresources to their canonical URLs, and serve those subresources if it's seen them inside another document? There are two questions- first, is your spec good enough to enable that facility where addressing can be well known- here, in this Json Resource Description spec presented yes, via URI templates, very good- and second, does the browser bother to inspect the JSON it sees? No? Well, I'm not super bothered by this academic interest not being materialized, knowing at least in principle the specs make it possible.
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.
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 t…
Earlier quoted context omitted.
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 MUST s to SHOULD s or MAY s if it makes sense for the communication channel to consider them optional.
That's great to hear. One particular example which I found needlessly strict is this: The request MUST contain a Content-Type header whose value is application/json. It MUST also include application/json as the only or highest quality factor. It makes sense for fully compliant implementation to have those headers, but they way I understand MUST here is that a server would reject any request without them.
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…
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.
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 be…
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,…