Work done and some questions

Reading

Read chapter 7 and skimmed through chapter 8 from the “RESTful Web Services” book, it is pleasant to read, however the examples are not hands-on examples, I would recommend the book to anyone who wants to know what REST is and most importantly what it isn’t, however if he already understands what REST offers and wants to create web services in frameworks and languages other than Ruby and Rails then the book won’t be of much help.

I bought an e-book called “RESTful PHP Web Services”, and started programming directly, the examples were very easy. Comparing the two books together “RESTful Web Services” is more authentic if you want theories on how things should be, however you can’t trust “RESTful PHP Web Services” on theories, because there are shortcuts and compromises for example the http Response codes that should be returned were not discussed, the only response code discussed was “200 OK”. In the “RESTful Web Services” book on each problem presented there is a “What might go wrong” section, discussing failure scenarios and suggesting http error codes that correspond semantically, this is an important aspect in making Web Services somewhat autonomous and standard. However the PHP book totally ignored it.

The Service (Non-Semantic)

The basic intended system was a simple service to create an annotated bibliography. It is a collection of references and comments on them. They can be added, updated and deleted.

Database Design

I very much simplified it, and designed a simple database this is the ER

There was a design option in making a reference a super-class with two subclasses: an inProceedings and an article, but this will complicate the service. Furthermore, I will combine them in one table after normalization, because Reference is related to both Annotation and Author. Also to optimize searching and displaying information since Reference is the main table and separating it into two tables would mean doubling the access requests. And finally the most important thing is to make the coding simpler :).
Any normalization needed was carried out, and then the tables were then created in MySQL.

Resource Design

Both books start solving problems by identifying the resources then giving them URLs. The services offered are designed in respect of the resources. This is done by answering the question “what should this resource offer as a service?” These functionalities are then mapped into semantically corresponding HTTP methods so that any service offered is identified by the URI and the HTTP method together.

URI	HTTP Method	Description
/Reference	GET	Fetch a list of all references
/Reference/{Query String}	GET	Search for references
/Reference	POST	Create a reference
/Reference/{Query String}	PUT	Modify certain references
/Reference/{Query String}	DELETE	Delete certain references
/Reference/{Reference}	GET	Fetch a reference
/Reference/{Reference}	PUT	Modify a reference
/Reference/{Reference}	DELETE	Delete the reference
/Reference/{Reference}/Annotation	GET	Fetches this reference’s annotation
/Reference/{Reference}/Annotation	POST	Create an annotation for this reference
/Reference/{Reference}/Annotation	PUT	Modifies this reference’s annotation
/Reference/{Reference}/Annotation	DELETE	Deletes this reference’s annotation
/Reference/InProceedings	GET	List conference papers
/Reference/Article	GET	List journal papers

Services in blue are implemented other services are not but are similar.

Something to bear in mind is that the URIs don’t relate to the file structure in the site. In fact there is no folder named /Reference, it is just a alias for a ref.php file which contains the logic for all the services (messy I know :) ) but it looks nice. Everything that comes after /Reference is considered a parameter sent to ref.php. I picked up the trick from Wiki’s Pretty URL. Ever wondered about their URLs e.g. http://en.wikipedia.org/wiki/Semantic_Web

I know I have :)

I was reading in Feilding’s dissertation how the URIs don’t have to reflect the file structure and now I understand what it means.

I’ve used a small traffic monitor to see the HTTP messages it’s called tcpmon

https://tcpmon.dev.java.net/

I designed the client to be other PHP files that consumed these web services. However the client could be designed in any language that supports HTTP and XML.

The Semantic Service

I haven’t implemented a Semantic RESTful Wed Service yet. The objective behind implementing it was to see if it can be done, and if so are there any constraints on the Semantic data. I found a paper “Bridging the semantic Web and Web 2.0 with Representational State Transfer (REST)” that discussed implementing RESTful Web Services so I started reading the paper and analyzing it instead of implementing the service because:

1-They have reached promising results and proved that RESTful Semantic Web Services can be done. Furthermore a small service like the one I was intending to implement won’t show much potential compared to the examples they had.

2-I discovered that merely converting XML to RDF in my service won’t add anything to what they came up with.

3-I needed many tools to deal with the Semantic data (A database, reasoner a webserver) to implement a more sophisticated service, and I didn’t have a specific significant problem to solve and haven’t dedicated much time to decide on which tools might be suitable.

About the paper

The objective of the authors was to show that REST and RDF can bridge between existing Web 2.0 services and Semantic Data.

Their approach was to take an existing Web 2.0 RESTful service augment it with describing semantics, and provide RESTful interface for some other Semantic data, enabling both in the end to be queried by SPARQL.

They used a Java tool named (SBWS) “Semantic Bridge for Web Services” (part of the BBN’s ASIO suite) it is a tool that wraps around WSDL or WADL and provides a SPARQL endpoint. It is similar to SAWSDL

They experimented with Amazon’s REST-based E-Commerce Services, an ontology of the web service is created and the WSDL file is annotated, after that SBWS can be used to query the service as if it was in RDF.

As to making Semantic data RESTful, they took another approach they called “Semantic REST”. It takes the REST operations and maps them into SPARQL RDF operations with some constraints.

The data constraints:

“Semantic REST requires that all requests containing an RDF graph reference the endpoint URI in every disconnected sub-graph included in the request.”

Explained elsewhere in the paper:

“the Read statement returns all triples for which the URI endpoint is either the subject or object”

They the divided the Semantic REST requests into Class-level endpoints which operates on entire class of resources and Resource-level endpoints which operates on individual resources. Tables below show the difference.

Class-level endpoints of Semantic REST¹

Operation	HTTP command	Request data format	SPARQL command	Response
List	GET	None	n/a	SPARQL Select result of all resources of the type specified by the URL
Query	GET	SPARQL	SELECT or CONSTRUCT	Query Results
Create	POST	None	n/a	Status 201 CREATED
Insert	PUT	SPARQL/Update	INSERT	Status 200 OK
Remove	DELETE	SPARQL/Update	DELETE or MODIFY	Status 200 OK

d
s
d

Resource-level endpoints of semantic REST¹

Operation	HTTP command	Request data format	SPARQL command	Response
Read	GET	Empty	n/a	RDF/XML
Insert	PUT	SPARQL/Update	INSERT	Status 200 OK
Remove	DELETE	SPARQL/Update	DELETE or MODIFY	Status 200 OK

They tested their system with a distributed query over the Amazon.com’s live REST-based service, an RDF triple store with employee data which had a SPARQL endpoint, and Semantic REST compliant replica of SemWebCentral. They used SQD (Semantic Query Decomposer) and connected to these three datasets and queried them as if they were one dataset. The query succeeded.

A question arises however what did they benefit from making the Semantic Data RESTful, or were they only showing that it is already RESTful? And that using SPARQL queries in specific ways enables accessing them.

Problems and limitations

-SPARQL (INSERT and DELETE): not yet added in the standard but are suggested to be added.

-Authorisation and Authenticity.

-Some public routers refuse to forward HTTP method DELETE