Oppgaven er ikke lenger tilgjengelig

Hypermedia RDF for driving applications

REST is a hot buzzword these days, but the essence is often not grasped: RESTful applications must be driven but the actual messages that are passed in the system, not some externally documented API. Hypermedia, in this sense, is not (just) some media embedded in another, hypermedia is the term for the content of the messages that does this. We'd like you to explore this in further depth, either by Javascript frontend programming, by exploring some other open problems, e.g. around authentication, or some deep backend programming.

Representational State Transfer (REST) is an architectural style that is popular on the web. You've probably heard the term, and seen many APIs that claim to follow this style. In most cases, they are probably not. It is frequently misunderstood, and therefore many APIs do not really take full advantage of the style.

The forgotten essence is that the application must be driven by the messages, for example HTTP messages, that is passed back and forth between the server and a client. You should always design your website so that humans can interact with it without looking up an external manual. Machines can't read your manual, so why should they have to? Out-of-band documentation is to be avoided.

If you do it right, you gain "View Source"-capability: I.e. developers can simply view the data you're sending them to learn how to use the API. "View Source" tends to win over time over APIs that have external documentation. You also ensure evolvability, since a developer still just have to relate to the viewed source, they don't need to track the version of your API. You also gain a lot in scalability by using REST.

Now, the Semantic Web provides something that we think would be great for this purpose: The Resource Description Framework (RDF). RDF would provide the data, and in RDF messages, you could tell the application what it can do in structured messages. You can also add reasoning to allow even more dynamicity.

In its simplest form, you can just create a simple Javascript library to interact with some simple predicates, like the ones proposed in this talk. But we want to go much further. It would be interesting to view the whole software architecture where the application shares Javascript between the server and the client, yet driven by RDF from several different sources.

One problem one will soon face in read-write-applications is that clients typically do not provide credentials to servers if they are not challenged, even though they are permitted to do that by the HTTP specification. Thus, the server will not tell the client what it can do in terms of write operations. You will need to suggest how to solve that.

A problem of a more fundamental nature is to answer these questions: To what extent can a client be autonomous and consume an API it has never seen before? Can it reason about the consequences of actions, will it be able to relate it to its own goals? And if so, what role do hypermedia and RDF play therein?

Finally, you can dive into the backend. If the application is a pizza delivery system, the RDF will detail the available pizzas, and then an order is the action of incrementing some counter by the number of the pizzas wanted. The RDF has to tell the client which counter to increment and how. But, for efficient sales, one may want to have drinks in the same message, but possibly only links to other sauces. There are many angles to this problem.

Emneord: semantic web, hypermedia, REST
Publisert 23. sep. 2013 17:56 - Sist endret 30. jan. 2014 13:41

Veileder(e)

Omfang (studiepoeng)

60