This link has been bookmarked by 388 people . It was first bookmarked on 10 Dec 2007, by alm.
-
06 Jun 17
-
25 Sep 15
-
05 Jun 15
-
a simplified, pragmatic definition: REST is a set of principles that define how Web standards, such as HTTP and URIs, are supposed to be used (which often differs quite a bit from what many people actually do). The promise is that if you adhere to REST principles while designing your application, you will end up with a system that exploits the Web’s architecture to your benefit.
-
using URIs to identify your key resources means they get a unique, global ID.
-
The URI.
-
To drive home this point: Imagine what an awfully horrid business decision it would be if an online store such as Amazon.com did not identify every one of its products with a unique ID (a URI).
-
h REST includes the idea of statelessness
-
REST mandates that state be either turned into resource state, or kept on the client.
-
-
23 May 15
-
12 May 15
Byron Cochraneeasy to understand
-
04 Jan 15
-
14 Nov 14
-
exploits the Web’s architecture to your benefit
-
consistent naming scheme
-
since years of object-oriented practice have told us to hide the persistence aspects as an implementation detail.
-
whether they represent individual items, collections of items, virtual and physical objects, or computation results.
-
whether they represent individual items, collections of items, virtual and physical objects, or computation results.
-
-
31 Mar 14
-
16 Mar 14
-
In a RESTful HTTP approach, you would have to get by with the generic interface that makes up the HTTP application protocol. You might come up with something like this:
-
-
09 Dec 13
-
30 Oct 13
-
heterogeneous application-to-application communication
-
REST, short for REpresentational State Transfer.
-
- Give every “thing” an ID
- Link things together
- Use standard methods
- Resources with multiple representations
- Communicate statelessly
-
Everything that should be identifiable should obviously get an ID
-
URIs make up a global namespace, and using URIs to identify your key resources means they get a unique, global ID.
-
-
23 Oct 13
-
23 Sep 13
-
09 Sep 13
-
REST is a set of principles that define how Web standards, such as HTTP and URIs, are supposed to be used
-
The promise is that if you adhere to REST principles while designing your application, you will end up with a system that exploits the Web’s architecture to your benefit.
-
- n summary, the five key principles are:
- Give every “thing” an ID
- Link things together
- Use standard methods
- Resources with multiple representations
- Communicate statelessly
-
I’m using the term “thing” here instead of the formally correct “resource” because this is such a simple principle that it shouldn’t be hidden behind terminology.
-
Everything that should be identifiable should obviously get an ID — on the Web, there is a unified concept for IDs: The URI.
-
URIs make up a global namespace, and using URIs to identify your key resources means they get a unique, global ID.
-
Note that the benefits of having a single, globally unified naming scheme apply both to the usage of the Web in your browser and to machine-to-machine communication.
-
To summarize the first principle: Use URIs to identify everything that merits being identifiable, specifically, all of the “high-level” resources that your application provides, whether they represent individual items, collections of items, virtual and physical objects, or computation results.
-
There is an even more important aspect to the hypermedia principle — the “state” part of the application. In short, the fact that the server (or service provider, if you prefer) provides a set of links to the client (the service consumer) enables the client to move the application from one state to the next by following a link.
-
To summarize this principles: Use links to refer to identifiable things (resources) wherever possible. Hyperlinking is what makes the Web the Web.
-
If you see a URI written on the side of a bus, you can enter it into your browser’s address field and hit return — but how does your browser know what to do with the URI?
-
It knows what to do with it because every resource supports the same interface, the same set of methods (or operations, if you prefer). HTTP calls these verbs, and in addition to the two everyone knows (GET and POST), the set of standard methods includes PUT, DELETE, HEAD and OPTIONS.
-
To summarize: For clients to be able to interact with your resources, they should implement the default application protocol (HTTP) correctly, i.e. make use of the standard methods GET, PUT, POST, DELETE.
-
how does a client know how to deal with the data it retrieves, e.g. as a result of a GET or POST request?
-
This illustrates why ideally, the representations of a resource should be in standard formats — if a client “knows” both the HTTP application protocol and a set of data formats, it can interact with any RESTful HTTP application in the world in a very meaningful way.
-
There is another way to exploit this: You can turn your application’s Web UI into its Web API — after all, API design is often driven by the idea that everything that can be done via the UI should also be doable via the API. Conflating the two tasks into one is an amazingly useful way to get a better Web interface for both humans and other applications.
-
Summary: Provide multiple representations of resources for different needs.
-
In other words, a server should not have to retain some sort of communication state for any of the clients it communicates with beyond a single request.
-
HTTP “instantiates” the REST uniform interface with a particular one, consisting of the HTTP verbs.
-
the Web, HTTP and URIs are the only major, certainly the only relevant instance of the REST style as a whole.
-
-
15 Aug 13
-
02 Aug 13
-
05 Jul 13
-
29 May 13
-
15 Apr 13
-
08 Apr 13
-
06 Mar 13
-
26 Feb 13
-
21 Jan 13
-
19 Dec 12
-
13 Dec 12
While the current mainstream clearly focuses on web services based on SOAP, WSDL and the WS-* specification universe, a small, but very vocal minority claims there’s a better way: REST, short for REpresentational State Transfer. In this article, I will try to provide a pragmatic introduction to REST and RESTful HTTP application integration without digressing into this debate. I will go into more detail while explaining those aspects that, in my experience, cause the most discussion when someone is exposed to this approach for the first time.
-
11 Oct 12
-
04 Oct 12
-
11 Sep 12
-
10 Sep 12
-
29 Aug 12
-
26 Aug 12
-
you can rely on one that has already been defined, works pretty well on global scale and is understood by practically anybody.
-
-
24 Aug 12
-
22 Aug 12
-
- Give every “thing” an ID
- Link things together
- Use standard methods
- Resources with multiple representations
- Communicate statelessly
-
Everything that should be identifiable should obviously get an ID — on the Web, there is a unified concept for IDs: The URI. URIs make up a global namespace, and using URIs to identify your key resources means they get a unique, global ID.
-
REST mandates that state be either turned into resource state, or kept on the client. In other words, a server should not have to retain some sort of communication state for any of the clients it communicates with beyond a single request. The most obvious reason for this is scalability — the number of clients interacting would seriously impact the server’s footprint if it had to keep client state.
-
-
12 Aug 12
-
09 Aug 12
-
04 Aug 12
-
17 Jul 12
-
13 Jul 12
-
18 Apr 12
-
05 Apr 12
-
04 Mar 12
-
Key REST principles
-
- Give every “thing” an ID
- Link things together
- Use standard methods
- Resources with multiple representations
- Communicate statelessly
-
To summarize the first principle: Use URIs to identify everything that merits being identifiable, specifically, all of the “high-level” resources that your application provides, whether they represent individual items, collections of items, virtual and physical objects, or computation results.
-
“Hypermedia as the engine of application state”, sometimes abbreviated as HATEOAS.
-
In short, the fact that the server (or service provider, if you prefer) provides a set of links to the client (the service consumer) enables the client to move the application from one state to the next by following a link. We will look at the effects of this aspect in another article soon; for the moment, just keep in mind that links are an extremely useful way to make an application dynamic.
-
The last principle I want to address is stateless communication. First of all, it’s important to stress that although REST includes the idea of statelessness, this does not mean that an application that exposes its functionally cannot have state — in fact, this would render the whole approach pretty useless in most scenarios. REST mandates that state be either turned into resource state, or kept on the client.
-
-
27 Feb 12
-
23 Feb 12
-
REST, short for REpresentational State Transfer
-
REST is a set of principles that define how Web standards, such as HTTP and URIs, are supposed to be used
-
The promise is that if you adhere to REST principles while designing your application, you will end up with a system that exploits the Web’s architecture to your benefit.
-
- Give every “thing” an ID
- Link things together
- Use standard methods
- Resources with multiple representations
- Communicate statelessly
-
Everything that should be identifiable should obviously get an ID — on the Web, there is a unified concept for IDs: The URI
-
Links are something we’re all familiar with from HTML, but they are in no way restricted to human consumption. Consider the following made-up XML fragment:
<order self='http://example.com/customers/1234' >
<amount>23</amount>
<product ref='http://example.com/products/4554' />
<customer ref='http://example.com/customers/1234' />
</order>If you look at the product and customer links in this document, you can easily imagine how an application that has retrieved it can “follow” the links to retrieve more information
-
Because the same interface is used for every resource, you can rely on being able to retrieve a representation — i.e., some rendering of it — using GET
-
GET supports very efficient and sophisticated caching, so in many cases, you don’t even have to send a request to the server.
-
I have a confession to make: What I explained is not really REST, and I might get flamed for simplifying things a little too much. But I wanted to start things a little differently than usual, so I did not provide the formal background and history of REST in the beginning. Let me try to address this, if somewhat briefly.
-
-
20 Feb 12
-
14 Feb 12
-
27 Jan 12
-
25 Jan 12
-
16 Dec 11
-
17 Nov 11
-
27 Oct 11
-
But there are other aspects that might be much more important: The statelessness constraint isolates the client against changes on the server as it is not dependent on talking to the same server in two consecutive requests.
-
-
23 Oct 11
Selenite Vingt-NeufIn this article, Stefan Tilkov provides a pragmatic introduction to REST (REpresentational State Transfer), the architecture behind the World Wide Web, and covers the key principles: Identifiable resources, links and hypermedia, standard methods, multiple
-
13 Oct 11
-
22 Sep 11
-
18 Sep 11
-
14 Sep 11
-
heterogeneous application-to-application communication
-
REST is a set of principles that define how Web standards
-
-
18 Aug 11
-
06 Aug 11
-
API design is often driven by the idea that everything that can be done via the UI should also be doable via the API.
-
although REST includes the idea of statelessness, this does not mean that an application that exposes its functionally cannot have state
-
The statelessness constraint isolates the client against changes on the server as it is not dependent on talking to the same server in two consecutive requests.
-
-
25 Jul 11
-
20 Jul 11
-
14 Jul 11
-
22 May 11
-
12 May 11
-
15 Apr 11
-
26 Mar 11
-
23 Mar 11
kjlengthese services is specific to the task — it’s an OrderManagement and CustomerManagement service we are talking about. If a client wants to consume these services, it needs to be coded against this particular interface — there is no way to use a client tha
-
12 Mar 11
-
08 Mar 11
-
02 Feb 11
-
25 Dec 10
-
24 Dec 10
-
21 Dec 10
-
17 Dec 10
-
24 Nov 10
-
15 Nov 10
-
09 Nov 10
-
06 Oct 10
-
16 Sep 10
-
02 Sep 10
-
REST is a set of principles that define how Web standards, such as HTTP and URIs, are supposed to be used (which often differs quite a bit from what many people actually do).
-
Use URIs to identify everything that merits being identifiable, specifically, all of the “high-level” resources that your application provides, whether they represent individual items, collections of items, virtual and physical objects, or computation results.
-
Hyperlinking is what makes the Web the Web.
-
GET’s semantics are defined in the specification, you can be sure that you have no obligations when you call it — this is why the method is called “safe”. GET supports very efficient and sophisticated caching, so in many cases, you don’t even have to send a request to the server. You can also be sure that a GET is idempotent — if you issue a GET request and don’t get a result, you might not know whether your request never reached its destination or the response got lost on its way back to you. The idempotence guarantee means you can simply issue the request again. Idempotence is also guaranteed for PUT (which basically means “update this resource with this data, or create it at this URI if it’s not there already”) and for DELETE (which you can simply try again and again until you get a result — deleting something that’s not there is not a problem). POST, which usually means “create a new resource”, can also be used to invoke arbitrary processing and thus is neither safe nor idempotent.
-
In a RESTful approach, an application might add a few million customer URIs to the Web; if it’s designed the same way applications have been designed in CORBA times, its contribution usually is a single “endpoint” — comparable to a very small door that provides entry to a universe of resource only for those who have the key.
-
if a client “knows” both the HTTP application protocol and a set of data formats, it can interact with any RESTful HTTP application in the world in a very meaningful way
-
REST in itself is a high-level style that could be implemented using many different technologies, and instantiated using different values for its abstract properties.
-
the idea that every resource should respond to the same methods. But REST doesn’t say which methods these should be, or how many of them there should be.
-
-
20 Aug 10
-
06 Aug 10
-
27 Jul 10
-
25 Jul 10
-
06 Jul 10
-
18 Jun 10
-
09 May 10
-
01 May 10
-
17 Mar 10
-
16 Mar 10
-
06 Mar 10
-
24 Feb 10
-
06 Feb 10
-
22 Jan 10
drhfuhruhurrGood intro to REST concepts: Identifiable resources, links and hypermedia, standard methods, multiple representations and stateless communication.
-
19 Jan 10
-
26 Dec 09
-
16 Dec 09
Would you like to comment?
Join Diigo for a free account, or sign in if you are already a member.