Difference between revisions of "SA-REST"
(→Introduction) |
|||
| Line 10: | Line 10: | ||
How, then, to address these limitations and find a less complex yet scalable approach? Reuse and data mediation have led to several proposals for Semantic Web services, leading to the W3C recommendation for the Semantic Annotation of WSDL and XML Schemas. But adding semantics to REST is more challenging than adding semantics to WSDL. Unlike WSDL, REST-based services are often embedded in Web pages written largely in XHTML. Although WSDL was specifically created to capture service descriptions and has a supporting schema for doing so, XHTML is a more general-purpose language that adds semantic annotations only to those page elements that wrap a service or a service description. | How, then, to address these limitations and find a less complex yet scalable approach? Reuse and data mediation have led to several proposals for Semantic Web services, leading to the W3C recommendation for the Semantic Annotation of WSDL and XML Schemas. But adding semantics to REST is more challenging than adding semantics to WSDL. Unlike WSDL, REST-based services are often embedded in Web pages written largely in XHTML. Although WSDL was specifically created to capture service descriptions and has a supporting schema for doing so, XHTML is a more general-purpose language that adds semantic annotations only to those page elements that wrap a service or a service description. | ||
| − | ==Background== | + | ===Background=== |
For an open, flexible and standards based approach to add semantics to RESTful services, we built the SA-REST description by borrowing the idea of grounding service descriptions to semantic metamodels via model reference annotations from SAWSDL. The key difference between SAWSDL and SA-REST is that while SAWSDL annotations were added to formal service descriptions in WSDL, SA-REST annotations will have to be added to the services that are usually described in web pages composed in HTML. Consequently, SA-REST uses RDFa and Gleaning Resource Descriptions from Dialects of Languages to add and capture annotations. | For an open, flexible and standards based approach to add semantics to RESTful services, we built the SA-REST description by borrowing the idea of grounding service descriptions to semantic metamodels via model reference annotations from SAWSDL. The key difference between SAWSDL and SA-REST is that while SAWSDL annotations were added to formal service descriptions in WSDL, SA-REST annotations will have to be added to the services that are usually described in web pages composed in HTML. Consequently, SA-REST uses RDFa and Gleaning Resource Descriptions from Dialects of Languages to add and capture annotations. | ||
| − | ==SA-REST in a nutshell== | + | ===SA-REST in a nutshell=== |
==Usage Scenarios== | ==Usage Scenarios== | ||
Revision as of 20:39, 16 September 2008
SA-REST is a simple and open format for enhancing Web APIs HTML or XHTML. In addition to HTML and XHTML, the SA-REST approach can also be used to enrich Atom, RSS, and arbitrary XML. SA-REST is one of several open microformat standards.
Contents
Introduction
Services based on the REpresentational State Transfer (REST) paradigm, a lightweight implementation of a service-oriented architecture, have found even greater success than their heavyweight siblings, which are based on the Web Services Description Language (WSDL) and SOAP (Reconciling Web Services and REST Services). By using XML-based messaging, RESTful services can bring together discrete data from different services to create meaningful data sets; mashups such as these are extremely popular today.
Current mashup tools and technologies
Although mashups fully embrace the idea of customization on the Web, read-write is another story. The complexity of application development using javascript makes it hard for average developers to create new mashups and to customize the existing ones. To solve this problem, several companies are developing tools for mashup creation that require little or no programming knowledge. These tools, exemplified by Yahoo! pipes, IBM's QEDwiki and Google's Mashup Editor, facilitate the selection of some number of RESTful Web services or other Web resources and chain them together by piping one service's output into the next service's input while filtering content and making slight format changes.
Limitations
One drawback of these tools is that they're limited in the number of services with which they can interact - typically, they deal with services internal to the company that created them (for example, Google Mashup Editor can use Google Maps) or to services that have standard types of outputs such as RSS or Atom. Anyone with experience in data interoperability and integration also knows that it's hard to integrate data through purely syntactic and structural means — semantic techniques are required. If a company developing a mashup tool wanted to add a new service that didn't have a standard output or that wasn't internal to their tool, it could modify its existing tooling in order to incorporate the new service's interface. However, this solution isn't scalable because of the rate at which new services are coming online. The need to change the tool itself also negates the idea of a customizable Web.
How, then, to address these limitations and find a less complex yet scalable approach? Reuse and data mediation have led to several proposals for Semantic Web services, leading to the W3C recommendation for the Semantic Annotation of WSDL and XML Schemas. But adding semantics to REST is more challenging than adding semantics to WSDL. Unlike WSDL, REST-based services are often embedded in Web pages written largely in XHTML. Although WSDL was specifically created to capture service descriptions and has a supporting schema for doing so, XHTML is a more general-purpose language that adds semantic annotations only to those page elements that wrap a service or a service description.
Background
For an open, flexible and standards based approach to add semantics to RESTful services, we built the SA-REST description by borrowing the idea of grounding service descriptions to semantic metamodels via model reference annotations from SAWSDL. The key difference between SAWSDL and SA-REST is that while SAWSDL annotations were added to formal service descriptions in WSDL, SA-REST annotations will have to be added to the services that are usually described in web pages composed in HTML. Consequently, SA-REST uses RDFa and Gleaning Resource Descriptions from Dialects of Languages to add and capture annotations.
