-
Notifications
You must be signed in to change notification settings - Fork 1
REST Definitions
This project was inspired by a thread on APPS-DISCUSS (Is there a sufficiently stable definition of REST?"). I am impressed by the number of people weighing in on the thread and how few of them a) are offering up a definition or pointing to one, and b) how many of them are trying to convince everyone there is no need for a definition or that achieving one is impossible.
So, I created this page to allow people to share their own definition of REST. Add your entry below and don't edit other entries. Let's collect up a list and see where it leads.
NOTE: All this material will be shared as a part of my RESTFest FiveInFive Talk "Is there a sufficiently stable definition of REST?" (talk). Don't add anything here you don't want a room full of Web Geeks (and the entire Internet) to see!
YOU CAN SHARE ANONYMOUSLY, IF THAT IS YOUR PREFERENCE
#####Selected Fielding Quotes on REST
###"I think REST is defined as:"
-
Your definition here (Your name & link)
-
REST is a coordinated set of architectural constraints that attempts to minimize latency and network communication while at the same time maximizing the independence and scalability of component implementations. This is achieved by placing constraints on connector semantics where other styles have focused on component semantics. REST enables the caching and reuse of interactions, dynamic substitutability of components, and processing of actions by intermediaries, thereby meeting the needs of an Internet-scale distributed hypermedia system. (Anon)
-
"REST is an architectural style that can be applied to a distributed hypermedia system.
It consists of the following architectural constraints:
- Client–server (mandatory)
- Stateless (mandatory)
- Cacheable (mandatory)
- Layered system (mandatory)
- Code on demand (optional)
- Uniform interface
- Identification of resources (mandatory)
- Manipulation of resources through representations (mandatory)
- Self-descriptive messages (mandatory)
- Hypermedia as the engine of application state (HATEOAS a.k.a the hypermedia constraint) (mandatory)
When mandatory constraints are observed, the following emergent properties are elicited:
- Performance
- Scalability
- Simplicity
- Modifiability
- Visibility
- Portability
- Reliability" (Jeff Michaud)
-
"Representational state transfer (REST) is an abstraction of the architecture of the World Wide Web; more precisely, REST is an architectural style consisting of a coordinated set of architectural constraints applied to components, connectors, and data elements, within a distributed hypermedia system. REST ignores the details of component implementation and protocol syntax in order to focus on the roles of components, the constraints upon their interaction with other components, and their interpretation of significant data elements." Wikipedia
-
REST: What matters is the URIs in the message body, not the URI of the message. (Karl. Not really a definition, but more a way to summarize the common mistake made about "REST" implementations.)
-
REST is an architectural style designed for network-based software systems that prioritizes architectural durability. Durability is achieved through evolvability and adaptability as the top desired properties of the style. To induce these desired properties, REST defines a client-server, stateless, uniform and layered style with a critical design constraint that distinguishes it from most other styles (the Hypermedia Constraint):
client interacts with the application entirely based on hypermedia controls provided dynamically by the application server(s).
-
REST is an architectural style for communicating messages over network-based software systems that prioritizes architectural durability. Durability is achieved through evolvability and adaptability as the top desired properties of the style. To induce these desired properties, REST defines a client-server, stateless, uniform and layered style with a critical design constraint that distinguishes it from most other styles (the Hypermedia Constraint):
client interacts with the application entirely based on hypermedia controls provided dynamically by the application server(s).
-
The REST architectural style is defined by a set of architectural constraints that induce the characteristics of evolvability and scalability into distributed applications that respect these constraints.
-
REST (REpresentational State Transfer) is the name given to an architectural style for networked software. The REST architectural style was first identified by Roy Fielding and is documented in his dissertation[Architectural Styles and the Design of Network-based Software Architectures]. The same term ("REST") and related terms ("RESTful", "Pragmatic REST", "High REST/Low REST" and others) can also be used to refer to a varying collection of design patterns for implementing services on the web over HTTP. Fielding addresses this discrepancy in the use of the term "REST" in his 2008 blog post, "REST APIs must be hypertext-driven." (Mike Amundsen)
Erik Wilde's (@dret) "it's complicated" definition:
REST is (at least) three things, and while it actually is the first thing, most people think it's the second one. That's fine, let's just make sure that we're clear about it not being the third one.
- An architectural style for building loosely coupled systems
- defined by a set of general constraints (principles)
- the Web (URI/HTTP/HTML/XML) is an instance of this style
- The Web used correctly (i.e., not using the Web as transport)
- HTTP is built according to RESTful principles
- services are built on top of Web standards without misusing them
- most importantly, HTTP is an application protocol (not a transport protocol)
- Anything that uses HTTP and XML/JSON (XML without SOAP)
- XML-RPC was the first approach for this
- violates REST because there is no uniform interface
- also violates REST because there is no hypermedia (HATEOAS)
Home :: Code of Conduct :: People :: Agenda :: Travel :: What Is RestFest?