Tuesday 13 January 2009

The Ticket Ontology Resource Design

Although I didn’t really stick to the WSMO example, I think that I captured the core functionality.

The Ticket Ontology and its RESTful interface enable the client to buy a trip ticket, by choosing the source and destination, the date and time, then providing personal and credit card info. The example is simplified to focus on the basic functions.

The Ticket instance {ticket_id} acts as a container for the ticket info, which is the person’s info, credit card info, source, destination and the confirmation number when the purchase is completed.

Parts of the URIs which are inside brackets are placeholders for specific instances.

URI

Method

Description

Client Sent

/TicketOntology/

GET

Gets the ontology

None

POST

N/A

-

PUT

N/A

-

DELETE

N/A

-

/TicketOntology/{source}/{destination}/

GET

Gets a trip’s schedule and prices

None

POST

Creates a new ticket instance, returns the ticket ID

Date and Time of the selected trip1

PUT

N/A

-

DELETE

N/A

-

/TicketOntology/{source}/{destination}/{ticket_id}

GET

Returns the ticket’s info, it differs based on what has been stored by the client

None

POST

N/A

-

PUT

To update or insert the person’s and the credit card info (What happens if the ticket is already confirmed, does this defy statelessness?)

person’s and the credit card info

DELETE

Deletes the ticket

-

/TicketOntology/{source}/{destination}/{ticket_id}/Conformation_Number/

GET

If everything is OK, returns a confirmation number, else returns an appropriate error response.

None

POST

N/A

-

PUT

N/A

-

DELETE

Cancels the trip’s booking if exists

-

/TicketOntology/{source}/{destination}/{ticket id}/Personal Info/

GET

Gets the person’s info if inserted

-

POST

N/A

-

PUT

To update or insert the person’s info

person’s info

DELETE

Deletes the persons info


/TicketOntology/{source}/{destination}/{ticket id}/Credit Card Info

GET

Gets credit card info inserted


POST

N/A


PUT

To update or insert the credit card info

Credit card info

DELETE

Deletes the credit card info


1. The choice of using the URI /TicketOntology/{source}/{destination}/ as a creation point for the ticket, could be taken a step further and this URI could be used instead /TicketOntology/{source}/{destination}/{date}/{time} . In that way the date and time won’t need to be sent as payload although having payload is acceptable, but the URI would be more expressive.

Some design issues rise here: changing the trip’s date and time by the client in the real world -which is likely to happen- will change the ticket’s URI, what does that mean semantically -in the “Semantic Web” sense-? A different instance maybe or I don’t know.

The same argument can be applied to the source and destination, they may change too.

How will that affect implementation?

What is the best way to do it and why?

2. The N/A fields in the table indicate that these methods cannot be used on the specified resources by a normal client. However they can be used by authenticated users. For example: on the URI /TicketOntology/{source}/{destination}/ , PUT could be used to adjust the schedule.

There are a lot of questions and issues I will discuss in the following post, they are still hovering around my head, I managed to pin some down but I still feel there are more which pop-up then disappear before I can catch them.

No comments:

Post a Comment