In 2000, Roy Fielding, one of the primary authors of the HTTP specification, wrote a doctoral dissertation titled "Architectural Styles and the Design of Network-based Software Architectures". In it, he coined the term “Representational State Transfer” to describe the networking principles that characterize the World Wide Web.
In the broadest terms, REST outlines how to define and address sources of specific information, commonly known as resources. Resources are referred to individually with a universal resource identifier, such as the URL used for Web addresses. The term REST often describes any simple interface used to transmit domain-specific data over HTTP without the need for additional messaging layers or session tracking.
REST is an architectural style, not a standard or implementation specification. The largest REST application is the Web itself, characterized by the use of HTTP for transport and URLs as addressing mechanisms. REST can support any type of media, and XML is the most popular method used to transport and represent structured information. REST is used with HTML, XHTML, RSS and proprietary XML vocabularies.
Systems that follow Fielding’s REST principles can be called RESTful, and some of REST’s advocates call themselves RESTafarians. But REST isn’t the only possible approach to building network applications, and there is some disagreement as to whether another might be preferable.
Basics of REST
REST involves several basic notions:
- Data elements. Resources (such as data objects), resource identifiers (network addresses, URLs), and representations of resources (HTML documents, JPEG images) are accessed through a standardized interface such as HTTP.
- Components. Origin servers, gateways, proxies and user agents communicate by transferring representations of resources through the interface, not by operating directly on the resources themselves. This is generally done using well-defined operations such as Get and Put.
- Connectors. Clients, servers and caches, as well as tunnels such as Socks and SSL connections, present an abstract interface for communication, hiding the implementation details of communication mechanisms.
- Stateless interaction. All requests made to connectors must contain all the information necessary to understand that request without depending on any previous request. This contrasts with the way many Web sites use cookies to maintain data between sessions. With REST, all messages must include all information necessary to understand the context of an interaction.
Why REST?
Many developers find REST challenging because it requires them to rethink their problems in terms of manipulating addressable resources instead of calling another routine to do something with that data. With RESTful design, Web services can be seen as simply a means of publishing information, components and processes to make them accessible to other users and machine processes. For example, the Atom Publishing Protocol, a RESTful application widely used for blogs, simplifies the process of publishing information and makes processes available to others so they can interact with that information. In general, REST requires less client-side software than do other approaches, because a single, standard browser can access any application and data resource.
No comments:
Post a Comment