Copyright © 2010 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
Web Applications have become widely adopted and are replacing public and corporate software infrastructure at an accelerated pace. The need for inter-operable Web Services and Web Service Providers is growing at the same pace. While the definition of these Web APIs will be handled by expert organizations such as messaging, storage, commerce, and computing providers, the discovery of these Web APIs can utilize existing standards to announce these Web Service endpoints. This document defines a mechanism and vocabulary for user agents that may be used to automatically discover Web APIs using standard web authoring technologies - HTML and RDFa.
This section describes the status of this document at the time of its publication. Other documents may supersede this document.
This is a very experimental document and has no status as a standards-track document at this time. While it is very early in the development of this document, all feedback is welcome.
git clone
git://github.com/digitalbazaar/payswarm.gitThis specification is the 05 January 2010 Editor's Draft.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
Using XHTML 1.1, HTML5 or XHTML5, one could use RDFa to express webservices that are available via a particular website.
For example, if a website supported a standard messaging API, every page on the site could have the following piece of markup:
We support the <a rel="webapi:services" href="services.html">Web Storage API</a>.
The services.html document would be marked up with RDFa, generating triples like the following:
<http://mysite.com/some/arbitary/path/api/sendmsg>
<http://w3.org/vocab/messaging-webapi#deliver-message>
"POST" .
User agents could then use this to make specific calls to a website using a standardized Web API protocol. If this sounds much like SOAP/WSDL/WSIL/UDDI it is, but much, much less complex.
Our experiences with SOAP/WSDL/WSIL and UDDI have been fairly awful. We needed a lightweight solution and settled on AJAX, REST and JSON for the RPC stack. The switch resulted in a simpler implementation, less code and an easier to understand Web API.
One of the goals of this document is to make publishing Web APIs as simple and straightforward as possible, using tools that many are already familiar with using to create.
The editors graciously acknowledge reviews and contributions from (in alphabetical order):
Some of the following references are normative while others are informative.
All references are non-normative.