I forgot to include the price of the ticket in the resource design, I’ve updated it now
First issue: Is it RESTful?
-Addressability: It is addressable.
-Uniform Interface
First issue: Is it RESTful?
-Addressability: It is addressable.
-Uniform Interface
- GET
Should be safe, meaning it doesn’t change the server state, a read-only method. I made a mistake with the confirmation number in the ticket example. It should not be issued by a GET request, it should be issued by a PUT or POST, then accessed by a GET request. I believe all other GETs are OK. - PUT
Should be idempotent, making 1request is like making 100. OK in the ticket example. - DELETE
Same as PUT - POST
No restrictions on POST
-Statelessness
Well I’m not sure I understand statelessness, but from what I read is that the state of the application is stored at the client side, and the state of the resource is stored at the server. I think that is the case in the ticket example.
-Connectedness
Inherently dealt with from the Semantic Web structure, I think :).
Second issue: (What have I really done?)
Analysing things done:
1-It hit me yesterday that I was exposing inputs and outputs of the service by giving them URIs, and offering access to them through HTTP requests. Inputs are Person’s Info and credit info and the output is Confirmation number.
2-I turned a synchronous transaction into an asynchronous transaction unintentionally. Meaning that usually a ticket is chosen, a person’s info his credit card info are given then if everything is OK a ticket is provided. All of that happens as one process. What I’ve done, however is let the client enter what it wants whenever it wants, then when the client wants to commit to the deal it sends GET to the /TicketOntology/{source}/{destination}/{ticket_id}/Conformation_Number/
-sending GET was a mistake it should have been PUT or POST-
What happens if the transaction must be synchronous? Don’t ask me I don’t know, I need an example, then I need to justify why it must be synchronous then try to think or search for a RESTful solution.
Third issue: The impact of OWL's structure on the design of URIs
Let’s take the ticket as a simple example: The ticket has the person’s info (first names, last name) and the credit card info (card holder name, card number, expiry date and others)
Should each part of the information be provided a RESTful interface?
For example the URI
/TicketOntology/{source}/{destination}/{ticket_id}/Personal Info/First_Names/
should it enable accessing the First_Names (getting, updating and so on)?
In the ticket example we chose to provide access to the person info and credit card info separately, but we could have combined them into one resource.
In other words do we expose every level of the ontology structure, or is leave it as choice for the service provider?
We can imagine a RESTful Semantic deployment engine, in which an ontology is given and the necessary functionality of inserting, updating and deleting is automatically generated or at least the procedure stubs where the functionality needed is more complex. The service provider can enter some options like: whether some resources should be exposed or not and which resources are inputs and which are outputs.
Fourth issue: What has RESTful Semantic Web got that WSMO hasn’t got?
I don’t know much about WSMO, I read some papers and articles and the nice example I’ve linked to before. I believe it as well as describing a service it enables it to be discovered on the Semantic Web, and to be reasoned about its applicability to certain problems.
-So where will the service description be in a RESTful Semantic Web Service? Will it be a property of the service ontology itself in our case the TicketOntology?
-Another point is that Web Services indicate what inputs they need and what outputs they provide.
In the Ticket example the inputs and outputs are modeled as resources. Is that RESTful? If it is then where should it be indicated?
Supposing we added the description of the service and defined inputs and outputs of RESTful Semantic services, what do we offer that WSMO doesn’t? A possible answer may be:
-An API to manipulate the Semantic data without much overhead.
-More decoupling.
-Integration of non-Semantic web services with Semantic Web services.
Hovering ideas caught :)
Well I’m not sure I understand statelessness, but from what I read is that the state of the application is stored at the client side, and the state of the resource is stored at the server. I think that is the case in the ticket example.
-Connectedness
Inherently dealt with from the Semantic Web structure, I think :).
Second issue: (What have I really done?)
Analysing things done:
1-It hit me yesterday that I was exposing inputs and outputs of the service by giving them URIs, and offering access to them through HTTP requests. Inputs are Person’s Info and credit info and the output is Confirmation number.
2-I turned a synchronous transaction into an asynchronous transaction unintentionally. Meaning that usually a ticket is chosen, a person’s info his credit card info are given then if everything is OK a ticket is provided. All of that happens as one process. What I’ve done, however is let the client enter what it wants whenever it wants, then when the client wants to commit to the deal it sends GET to the /TicketOntology/{source}/{destination}/{ticket_id}/Conformation_Number/
-sending GET was a mistake it should have been PUT or POST-
What happens if the transaction must be synchronous? Don’t ask me I don’t know, I need an example, then I need to justify why it must be synchronous then try to think or search for a RESTful solution.
Third issue: The impact of OWL's structure on the design of URIs
Let’s take the ticket as a simple example: The ticket has the person’s info (first names, last name) and the credit card info (card holder name, card number, expiry date and others)
Should each part of the information be provided a RESTful interface?
For example the URI
/TicketOntology/{source}/{destination}/{ticket_id}/Personal Info/First_Names/
should it enable accessing the First_Names (getting, updating and so on)?
In the ticket example we chose to provide access to the person info and credit card info separately, but we could have combined them into one resource.
In other words do we expose every level of the ontology structure, or is leave it as choice for the service provider?
We can imagine a RESTful Semantic deployment engine, in which an ontology is given and the necessary functionality of inserting, updating and deleting is automatically generated or at least the procedure stubs where the functionality needed is more complex. The service provider can enter some options like: whether some resources should be exposed or not and which resources are inputs and which are outputs.
Fourth issue: What has RESTful Semantic Web got that WSMO hasn’t got?
I don’t know much about WSMO, I read some papers and articles and the nice example I’ve linked to before. I believe it as well as describing a service it enables it to be discovered on the Semantic Web, and to be reasoned about its applicability to certain problems.
-So where will the service description be in a RESTful Semantic Web Service? Will it be a property of the service ontology itself in our case the TicketOntology?
-Another point is that Web Services indicate what inputs they need and what outputs they provide.
In the Ticket example the inputs and outputs are modeled as resources. Is that RESTful? If it is then where should it be indicated?
Supposing we added the description of the service and defined inputs and outputs of RESTful Semantic services, what do we offer that WSMO doesn’t? A possible answer may be:
-An API to manipulate the Semantic data without much overhead.
-More decoupling.
-Integration of non-Semantic web services with Semantic Web services.
Hovering ideas caught :)
No comments:
Post a Comment