So after reading the last blog Snookie and Topher were even more interested in this REST thing. Searching the Internet for examples they found the following REST URI* which returns a dictionary definition of the word “set”:
http://www.bti360.com/dictionary/set
“Wait a second, that looks just like a website address?” they exclaimed, wanting to know what it all meant. Resources and verbs, my friends, think resources and verbs.
Resources are the actual “things” that are being exposed in a web service. In the example above, “/dictionary” is the resource and “/set” is a sub-resource. What can we do with these resources? Well, that’s where the verbs come in.
RESTful web services take advantage of common HTTP methods in order to perform operations on a resource; these HTTP methods are referred to as REST verbs. The most commonly used verbs include:
| REST(HTTP) | Operation |
|---|---|
| POST | Create |
| GET | Retrieve |
| PUT | Update |
| DELETE | Delete |
One nice characteristic of REST verbs is that the URI does not change when different operations are performed. For example, the same URI given at the top can be used to:
- Create the word set in the dictionary we use the HTTP POST
- Retrieve the definition of the word set in the dictionary we use the HTTP GET
- Update the definition of the word set in the dictionary we use the HTTP PUT
- Delete the word set from the dictionary we use the HTTP DELETE
So Snook and Topher, what did you learn today? The “web address” that you saw is actually a REST URI that can be used to perform interesting actions (create, read, update, delete) on a particular resource. How about that? You both now know some basics for interacting with a RESTful web service.
Please note: REST URI’s should not be pre-constructed by client code. In fact, they should be treated as opaque identifiers that are meant to be discovered by following hyperlinks (the HATEOAS REST constraint will be discussed later… so stay tuned)
* A URI is the name and web address of a resource (an identifier)