Hi Danny and all, The criterion our current HTTP Services are missing to qualify as a REST API is the hypertext constraint.
To consume a REST service one should need nothing more than an entry-URI and a common media-type. Now for semantic REST service the design effort is not the actual media-format but the ontology. The client does a GET on the Rest Service URI and its gets a graph describing the service. The client should not need to know about various HTTP URI and how the should be invoked the client need only to understand one of the supported RDF formats and the ontology. As for the naming scheme: I don't think we need to have separate URIs for representations as this is the case for DBPedia. In stanbol representations are secondary, its about the resources. Cheers, Reto On Mon, Feb 18, 2013 at 1:04 PM, Danny Ayers <[email protected]> wrote: > Reto just mentioned: > [[ > I'm working on the > archetype which shows how RESTfull services can be build. Stanbol was > always about REST, yet we are not yet providing a single REST service. With > the RDF based frontend we get closer to this. As standard RDF formats and > well defined ontologies will satisfy the hypermedia requirement of REST. > ]] > > I'm putting RESTful access in place in User Management (as well as > browser-based and Web 2.0 style APIs). I'm just wondering if we need a > separate naming scheme for URIs that are addressing the RDF data, > something vaguely along the lines of dbPedia's ./page (for HTML) and > ./resource (for RDF), or whether simply ignoring that distinction and > just keying off media type is preferable. > > Currently I've got e.g. - > > Get user Turtle : > > curl --user admin:admin -H "Accept:text/turtle" > http://localhost:8080/user-management/users/anonymous > > Any thoughts? > > Cheers, > Danny. > > -- > http://dannyayers.com > > http://webbeep.it - text to tones and back again >
