Hypermedia RDF for driving applications
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.
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.