REST is an architectural style. It is a formalisation of Fielding's observation how the Web works.
A RESTful interface follows those principles and must employ hyperlinks (links in HTML, XLink in XML, _links property in HAL+JSON) and/or hypermedia controls (forms, XForms) and standard HTTP methods to assert state on resources. Resources are adressed by URIs.
An interface description concentrates on describing the semantics of media types of the resources (unless you were clever and picked an appropriate one that already exists) and link relations ("a", "link", "area" element with "rel" attribute in HTML; link objects in HAL+JSON; RFC 5988 Link headers for any media type). Link relations are standardised by IANA, but you can make your own one and assign some semantics to it by coining a URI. When an interface describes particular URIs (what you typically get when you google for REST interface examples), it's doing it wrong. An interface implementation allows a user agent to discover resources through hyperlinks and what you can do with them through an OPTIONS request. You can recognise a REST n00b by their lack of talking about link relations, which is so far everyone else's answers. I must consider colund's and dclara's answers as wrong/unhelpful because their explanation is so limited and unprecise.
This is the most accurate answer I've seen here (in terms of how Fielding described it).
The way he defines it in the dissertation is as a series of architectural constraints which evoke certain properties [1]. Those constraints are titled with "Client-Server", "Stateless", "Cache", "Uniform Interface", "Layered System", and "Code-On-Demand".
Your description of link relations is also correct. Links are the basis of all REST interoperation, whether for humans or APIs. I've been evangelizing the use of the Link header [2], which benefits from
1) a standard format regardless of content-type
2) the ability to be fetched with HEAD
3) the "relation type", which can be used to make strong assumptions about the endpoint
The only misleading part of this is "must employ...standard HTTP methods to assert state on resources". REST does not require using HTTP -- in fact, your own first link states, as its first rule, "A REST API should not be dependent on any single communication protocol".
Its true that whatever protocol(s) it uses should be used in standard (not resource-specific) way, but there is no requirement that HTTP be the only protocol, or one of the protocols, used.
This is one of the things I don't understand. Architectural style for what, interfaces?
> must employ hyperlinks
A weird restriction imho. Links make sense for web pages read by humans. But APIs? Yes, links are nice to quickly get to know the API, to test it via a browser but they're not that important.
> A weird restriction imho. Links make sense for web pages read by humans. But APIs? Yes, links are nice to quickly get to know the API, to test it via a browser but they're not that important.
The use of hypermedia is central to REST -- if you think "hyperlinks aren't important to APIs", that's equivalent to reject the REST architecture.
In REST, you don't need a map of service endpoints or conventions about locations to consume an API. You need to know one resource location, and understand the representation of the resource that can be retrieved there, and from that the rest of the API should be discoverable -- moreover, the locations of the other resources can change and you can still use the API.
(And this is scalable, so that what is from one perspective the "root" resource location for one API can also be a link provided by another resource, such that if you know how to retrieve the latter resource, the location of the other API root can change and you can still consume it.)
Architectural style for building scalable applications. Fielding wasn't talking about APIs specifically.
There's nothing "weird" about links in APIs. For an easy metaphor, think of "links" in APIs as you think of foreign keys in your database tables. Link doesn't just mean something you can click :)
A RESTful interface follows those principles and must employ hyperlinks (links in HTML, XLink in XML, _links property in HAL+JSON) and/or hypermedia controls (forms, XForms) and standard HTTP methods to assert state on resources. Resources are adressed by URIs.
An interface description concentrates on describing the semantics of media types of the resources (unless you were clever and picked an appropriate one that already exists) and link relations ("a", "link", "area" element with "rel" attribute in HTML; link objects in HAL+JSON; RFC 5988 Link headers for any media type). Link relations are standardised by IANA, but you can make your own one and assign some semantics to it by coining a URI. When an interface describes particular URIs (what you typically get when you google for REST interface examples), it's doing it wrong. An interface implementation allows a user agent to discover resources through hyperlinks and what you can do with them through an OPTIONS request. You can recognise a REST n00b by their lack of talking about link relations, which is so far everyone else's answers. I must consider colund's and dclara's answers as wrong/unhelpful because their explanation is so limited and unprecise.
http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hyperte... http://isitrestful.com/