HyperJSON + path expressions

[Manuel Simoni]

I just re-read Kris Zyp's post at
http://www.sitepen.com/blog/2008/06/17/json-referencing-in-dojo/
again, and I agree that the case for JSON path expressions is strong.

Here's one thought: HyperJSON as I outlined it on restful-json [1]
could be used together with a new URL scheme for path expressions:

Your example, the following JSON document from Kris' blog post:

{"name":"Kris",
"father":{"name":"Bill","wife":{"$ref":"$.mother"}},
"mother":{"name":"Karen"}}

would become this in HyperJSON:

{"name":"Kris",
"father":{"name":"Bill","wife":{"$href":"jsonpath:$.mother"}},
"mother":{"name":"Karen"}}

And, borrowing from XPath, we could also do
http://example.com/jsondocument#jsonpath:$.someProperty

What I like about this scheme is that it gives us the same generality
as HTML hyperlinks PLUS the JSON-specific path expressions.

-- Manuel

[1] http://groups.google.com/group/restful-json/browse_thread/thread/8c33618df87d85f8

[Kris Zyp]

> And, borrowing from XPath, we could also do
> http://example.com/jsondocument#jsonpath:$.someProperty
>
> What I like about this scheme is that it gives us the same generality
> as HTML hyperlinks PLUS the JSON-specific path expressions.
>

Well, I never thought of using a new URL scheme. I thought that was
generally avoided if it all possible. Also, Jeni Tennison mades a good
point [1] about how we could use JSONPath in the fragment identifier
with HTML representations of the same resource as well if we try to
avoid certain characters. That is one could have a URL,
http://example.com/jsondocument#someProperty that may have meaning in
both the JSON and HTML representation of the resource. We would lose
that with a new URI scheme.

[1]
http://groups.google.com/group/restful-json/browse_thread/thread/6beef1547c11426a/ff2451700049fac1

[Kris Zyp]

Also another thought (and once again pulling from the wisdom of Jeni
Tennison [1]), it seemed like most of us agreed with Jeni that we
probably will want to have two different RESTful JSON media types (maybe
one of the could actually be called HyperJSON and the other something
else, I don't know). One would be a "natural" unobtrusive JSON media
type that merely specifies how to do identify subresources in existing
JSON data and do referencing with minimal JSON structural implications,
and another media type that provides more structure for defining a
robust set of metadata for resources and sub-resources (with hopefully
semi-compatible referencing and other operational characteristics). I
actually thing your target defining idea could fit into either or both
of these media types, but it would look different in each one.
Kris

[1]
http://groups.google.com/group/restful-json/browse_thread/thread/784470ea4fdcba78/aa8461f654c9eb80?lnk=gst&q=jeni#aa8461f654c9eb80

[Ernest Prabhakar]

Hi all,

On Oct 30, 2008, at 12:23 PM, Manuel Simoni wrote:
> Here's one thought: HyperJSON as I outlined it on restful-json [1]
> could be used together with a new URL scheme for path expressions:

FYI, I've added these posts to the wiki:

http://microformats.org/wiki/rest/json#Proposals

Hopefully somebody will soon start implementing these so we can start
converging on a real-world spec. :-)

-- Ernie P.

[Kris Zyp]

>
> FYI, I've added these posts to the wiki:
>
> http://microformats.org/wiki/rest/json#Proposals
>
> Hopefully somebody will soon start implementing these so we can start
> converging on a real-world spec. :-)

I have implemented a number of the RESTful JSON ideas in the two
projects I am involved with (I think I may have mentioned this before):
Dojo as a user agent, and Persevere as a server. I hope that these could
be useful to the group as testable implementations of some of our ideas,
and it is certainly my intent to continue implementing the ideas from
this group. Currently Dojo 1.2 and Persevere support:

* Hypertext enabled JSON (or as I have called it previously, JSON
referencing in the JSON resources proposal, or as HyperJSON as
Manuel called it (although he modified it a little)) for
hyperlinking/referencing - Dojo supports resolving hyperlinks by
relative URL and fragment identifier path references (JSONPath).
Persevere supports path-based references as well, but does not yet
utilize the fragment identifier approach, but I can make that
change soon.
* Paging via Range/Content-Range headers with the "items" range unit
- The one difference between what we have discussed is that
currently Persevere and Dojo rely on each Ranged response being
syntactically correct JSON instead of textually subsets (for
example Range: items=0-1 would return ["value1","value2"] instead
of ["value1","value2",)
* JSONQuery - Implemented in both
* Standard HTTP operations (PUT, POST, DELETE with proper status
codes and Location header usage) - Implemented in both.

I haven't implemented any of the more structured resource
metadata/hyperlinking specification ideas yet (like John's "JSON
Collections" proposal or Subbu's "Generalized Linking") as they still
seemed up in the air. I would be glad to do that, and the "Generalized
Linking" structure may be specific enough to implement, although I would
probably have some questions/concerns. If anyone has any other ideas
from our discussions that they would like to see implemented soon, feel
free to let me know, and I can see if get them implemented so you can
test them out (no guarantees of timelines).

Also, if anyone is interested in working on and contributing to either
of these projects, I would certainly be glad to help them get started. I
think both of these are cool projects for developing and furthering
JSON-based REST architecture.

Kris

[Ernest Prabhakar]

Hi Kris,

On Nov 6, 2008, at 8:39 PM, Kris Zyp wrote:

> I have implemented a number of the RESTful JSON ideas in the two
> projects I am involved with (I think I may have mentioned this
> before):
> Dojo as a user agent, and Persevere as a server.

Sorry, yeah, didn't mean to overlook that. I guess what we need is
someone *else* write an app that talks to Kris's servers, so we can
claim "two independent implementations"...

-- Ernie P.

[Kris Zyp]

No problem, my main point was to let others know that these projects are
open for other's ideas to be tested on as well (and they already have an
existing foundation to start upon), and I agree that that would be great
to have independent implementations of these concepts. However, I think
that independent implementations could be much more easily realized if
we break the different apart the orthogonal components of JSON-based
REST architecture rather than treating them a single monolithic
specification. As a separate components, there is already good progress
towards independent implementations among several of these concepts:

* Hypertext enabled JSON/JSON Referencing -
I cc'ed this group on Douglas Crockford's recent implementation of a path-based referencing library (cycle.js). Crockford's libraries are usually considered pretty normative. This library isn't completely interoperable, as he used "$" prefixed paths (per the JSONPath specification), but RESTful consideration would suggest "#" prefixing (treating paths as fragment identifiers, and I have changed Dojo and Persevere accordingly).

* JSONQuery
While JSONQuery specifically hasn't been implemented by anyone else, it is basically just the name for an extended and more tightly specified version of JSONPath. JSONPath has seen several independent implementations [1].

* Standard HTTP operations (PUT, POST, DELETE with proper status
codes and Location header usage) - Implemented in both.

Using PUT, POST, and DELETE with JSON data is implemented by a number of
systems (as you have included in the page on microformats.org). The main
interoperable issue is the variety of properties and structures used for
defining and resolving hyperlinks/locations. The email I just sent out
it is another attempt at resolving these differences with minimal
modification to these systems.

Thanks,
Kris

[1] http://code.google.com/p/jsonpath/