views:

248

answers:

6

I've tried searching but I can't figure out how to access data via a RESTful interface. I'm looking for just example code that shows someone access some data from some imaginary web service using its API. A simple "how-it-works" explanation would be helpful too.

+1  A: 

Kind of a hot topic. Expect an explosion of answers ;)

REST works on the principle of using HTTP request methods to determine an application's (the REST server) action on an object. The 4 HTTP methods commonly used are GET, POST, PUT and DELETE.

Say, for example, the object in question is user data. The REST url/object might look something like http://mydomain.com/services/user

If we wanted to get information about existing user, you could GET http://mydomain.com/services/user/someuserid.

If we wanted to create a user, you would use POST http://mydomain.com/services/user and the request body would contain the user's information.

If we wanted to change a user's info, you would use PUT http://mydomain.com/services/user/someuserid. Again, the request body would contain the user's new information.

If we wanted to delete a user, you would use DELETE http://mydomain.com/services/user/someuserid

In summary, the 4 different HTTP methods generally have these meanings, but can differ from server to server, depending on how RESTful it is:

  • GET == get, fetch, retrieve, and other synonyms
  • POST == create, add
  • PUT == change, alter
  • DELETE == delete, remove
Justin Johnson
-1: Justin, he wanted help on how to _use_ a RESTful API.
John Saunders
First, watch your language. I've flagged your comment. Second, the post may be "useful", but since the question was about "how to use a RESTful API", and the answer is about "what is a RESTful API", I think it should be clear that this is a useful answer to a different question.
John Saunders
-1 This is clearly RPC, there is so much coupling going on. There's nothing REST about this.
Wahnfrieden
I disagree with your disagreeing. He asked for examples for an imaginary API and a *simple* "how it works" explanation, which I provided. Further, the examples are RESTful, and agree with <http://en.wikipedia.org/wiki/Representational_State_Transfer#RESTful_web_services>. Lastly, since you bring it up, while it is more clearly defined, REST is a subset/type of RPC in that when a client consumes a REST service/resource, procedures on remote machines are executed. He wanted simple and I kept it that way.
Justin Johnson
@Justin Yes I know REST is a subset of RPC. However, it is a specialized form of RPC with additional constraints, which must be followed in order to call something REST. Please don't reference the Wikipedia article, which Fielding himself says is very confused and not based on authoritative sources.
Wahnfrieden
A: 

http://oreilly.com/catalog/9780596529260/

Chapter 2 and 11 - sample code at the website.

mbehan
-1: don't just post a link.
John Saunders
+1: posting a link is fine if it guides you in the correct direction. I've had many an answer solved by a simple link.
Jason
See http://meta.stackoverflow.com/questions/7515/why-is-linking-bad/7519#7519, as well as many other meta discussions on the topic.
John Saunders
A: 

If you were looking for an experience similar to what you get with a SOAP-based service and "Add Service Reference" or "Add Web Reference", then you're not going to find it. REST-based services are so lightweight that tools are unnecessary.

You'll just use the WebRequest class to POST or GET from the service. You'll create the XML to send using LINQ to XML or XML Serialization, or whatever else you like. When the response comes back, you'll parse it, just like any other XML.

As an example, see "A REST Client Library for .NET, Part 1" (sorry, there is no part two).

John Saunders
voting people down to promote your own answer and link to your website does not help your cause, regardless of how right you may be.
Jason
If you were right about the reason I voted them down, then I would feel bad about myself. However, since I voted them down because they did not address how to _use_ a RESTful API, I don't feel so bad. I also don't have handy a URL to any other example of _using_ a RESTful API, so I broke down and used the URL to my "Part 1", despite the embarrassing fact that there is no Part 2. Nope, I'm feeling ok right now...
John Saunders
You missed the part about having the client depend on the content-type of responses for choosing how to parse the documents.
Wahnfrieden
No, I didn't miss it - it's not in the API (unless I missed that).
John Saunders
BTW, I'm going to have some time coming up to do some more extensive blogging. Can you recommend an API that is a good example of a REST API? It would be good to have a blog post about a true REST API. In retrospect, I want to rename my April post to something like, "a client library for a non-SOAP, non-REST, non-XML/RPC Web Service".
John Saunders
@Downvoter(s): you'd make more of a difference in the world if you said why you've downvoted this answer, than by reducing my rep by 0.0167%.
John Saunders
+1  A: 

Check out the Sun Cloud API. It's AFAIK the first (and still one of the only) APIs to embrace the hypermedia as the engine of application state (HATEOAS) constraint in its design and documentation. This seemingly minor constraint turns out to be one of the central ideas of REST and it has been consistently ignored over the last few years.

The Sun Cloud documentation has some nice examples of sample requests, responses, and what hypertext-driven media types might look like.

Rich Apodaca
-1: Does the Sun API answer the question about how to _use_ a REST API?
John Saunders
+1 because the provided link has examples on how to use its REST API.
Jason
I just checked that link. It's the link to the entire API spec. If the link had been to a _usage_, I would not have voted down. The link answers the question the same way a link to a dictionary answers the question "what is documentation?" If Rich were to add a link to a usage of part of that API, then I would remove the downvote.
John Saunders
@Jason: in response to your comment on your deleted answer: if the OP had never seen a RESTful API, then showing him his first RESTful API would help him use one more than not showing him his first RESTful API. However, the fact that he's asking how to use one suggests he's already seen a RESTful API, and still wants help in _using_ one.
John Saunders
+1  A: 

Here is some pseudo code that I just used to answer a similar question.

The general flow of any http based RESTful client inquiry should go something like this:

  1. Do a HTTP GET on the root url of the API.
  2. Parse the response based on the media type specified in the http header "Content-Type".
  3. Does the response contain the answer to my question?
  4. If yes then extract the information and do what you want with it.
  5. If no, then does the response contain a link to another resource that may have the answer to my question.
  6. If yes then do a HTTP GET or POST on that link based on what the media type definition tells you to do. Goto step 3.
  7. If no then stop looking and tell the user you cannot find an answer.
Darrel Miller
Darrel, that seems like a fairly non-deterministic way to do things, especially if it's important to get an answer. It raises questions like, "where are the media types documented", "are they documented unambiguously", and "how do I know if a resource may have an answer to my question". It might be one thing to tell a user "no", but another if some business operation has to fail because I reached step 7, and I have to be the one to explain why.
John Saunders
It is essential that the client code understand the media-type, so why do I care "where" the media types are documented? The client will respond precisely based on its media-type handling code, whether the media-type is ambiguously documented is irrelevant to "how do you use a RESTful API".If the client understands the media-type and it knows what it is looking for, it should know whether the media-type contains the information. If a business operation requests a resource that does not exist, I would expect the system to be able to deal with that scenario.
Darrel Miller
Darrell, the scenario I'm thinking of is that I have a business problem to solve, and I've been told to go use some particular RESTful API to solve it with. I'm wondering how media types are documented so I know when I've understood the media types returned by the service.
John Saunders
I mean, you say, "it is essential that the client code understand the media-type", but since the client code is written by programmers, I'm asking how a programmer can learn how to make the client code understand the media type.
John Saunders
@John Well the normal process is that if you want to expose some data on the web, you look for existing media-types at IANA that suit your requirement and if you cannot find one, you have the option of creating your own in the vnd subtree, or trying to register a new public one. See http://www.iana.org/assignments/media-types/application/ Here is another example http://www.rfc-editor.org/rfc/rfc5222.txt
Darrel Miller
@John Providing a service on the web that delivers application/xml is not much more useful than providing a random stream of bytes if your objective is to reduce client/server coupling.
Darrel Miller
My thought was to make the schema available.
John Saunders
@John that's what a REST API document is for.
Wahnfrieden
A: 

After a little more looking, I found something that gave me the information I needed. http://developer.yahoo.com/php/howto-reqRestPhp.html

chustar