Representational State Transfer (Software architecture)
Enlarge text Shrink text-
Save successfulThe item can be found in your Personal ZoneשגיאהLog in to your account to save
Information for Authority record
Other Identifiers
- Work cat.: 2009002859: Scriber, K. Effective REST services via .NET, c2009:ECIP galley (REST, architectural concept; archtectural style; used for programming for the Internet to create Web applications and services and being called RESTful services; Representational State Transfer)
- Wikipedia, viewed Jan. 28, 2009(Under: Representational State Transfer; REST, a style of software architecture for distributed hypermedia systems such as the World Wide Web; the terms "representational state transfer" and "REST" were introduced in 2000 in the doctoral dissertation of Roy Fielding)
- ASTI, viewed Jan. 28, 2009(in abstract: Representational state transfer; REST)
- Inspec, viewed Jan. 28, 2009(uncontrolled index heading: Representational state transfer architecural model)
- EI, viewed Jan. 28, 2009(in abstract: "... varations of the World Wide Web's REpresentatioal State Transfer (REST) architectural style that support distributed and decentralized systems")
Wikipedia description:
REST (Representational State Transfer) is a software architectural style that was created in 2000 to guide the development of the World Wide Web. REST is defined as a set of six constraints for the ideal architecture of a distributed, Internet-scale hypermedia system such as the Web: Client/Server, Stateless, Cache, Uniform Interface, Layered System, and Code on Demand. (See The six constraints, below.) The motivation for these six constraints is to grant the system desirable properties such as modularity, scalability, latency-reduction, security, and compatibility with legacy systems. (See Implied architectural properties.) REST has been used to create stateless, reliable, web-based applications. An application that adheres to the REST architectural constraints may be informally described as RESTful, although this term is more commonly associated with the design of HTTP-based APIs and what are widely considered best practices regarding the "commands" (HTTP methods) a resource responds to, while having little to do with REST as originally formulated—and is often even at odds with the concept.
Read more on Wikipedia >