AJAX like URLs as URIs for resources ….

Hi

I am trying to get a feel for what is good practice in URL construction for using AJAX RESTful calls to return JSON objects giving RDF descriptions.

Note - I am trying to be careful in this message to use 'URL' when I wish to emphasize the GET or POST operations and 'URI' when I wish to emphasize the identifier. Typically I am imagining the same character string for both.


The basic use patterns maybe:

1) GET a resource.

The client calls GET on the resource URL and get back a representation of the resource as a bundle of JSON, which in practice is determined by:
   a) take the retrieval URL
   b) use as the URI of a resource 
   c) find the concise bounded description [1] for the resource using our triple store
   d) convert the CBD into JSON

2) update the description of a resource

The client sends similar JSON as from 1(d) to the server as the body of a POST request to the same URL and the server updates the triple store appropriately.

===

Now, as the owner of the server, I get to determine the design of my URL space, and no-one else is meant to second guess me.
However, the more I follow good practice, the happier other people will be with me; and I like to make people happy (at least some of the time)

In practice there are several different sort of resources of interest ….

A) classes in my ontology
B) properties in my ontology
C) individuals in my ontology
       Actually, in my application, I know ahead of time that individuals of certain classes are particularly interesting, e.g.
           patients
           drugs
D) classes, properties and individuals in imported ontologies


In typical AJAX like usage web apis tend to group things by type so that I could have URLs like:

https://example.syapse.com/eg/class/4
https://example.syapse.com/eg/property/35
https://example.syapse.com/eg/individual/17
https://example.syapse.com/eg/patient/507
https://example.syapse.com/eg/drug/3

And these would give back some AJAX representing resources identified by these URIs; and be fairly friendly to the client code: which can use relative URI with a base:

https://example.syapse.com/eg/

and all the identifiers are 'easy to work with'

In the first instance, the client code is written by people sitting at the same desk as me, so out-of-band communication is easy; however sooner or later larger effects will hit with D and we will probably need a web service that takes an arbitrary URI argument and returns the CBD in JSON.

Also, at some point, we may envisage other 3rd party clients for which out-of-band communication is harder

I am trying to understand these issues with respect to:
- respect for client side developers who would like easy to use JSON oriented, Web APIs, without too much semantic web
- respect for semantic web practice (which for instance would tend to put all the URIs above in the same namespace)
- respect tor RESTful architectural principles, such as [2], in which Roy lambasts out-of-band communication, and 'types' being made visible to the client

Note that the first of these goes against the general catch all solution of using a SPARQL end point and being done with it. Yes, we obviously need a SPARQL end point for complex query function, and it could do everything … but …

Any thoughts?

Jeremy



[1] http://www.w3.org/Submission/CBD/
[2] http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

Received on Friday, 22 February 2013 16:01:49 UTC