22

I've read a couple of definitions and discussion on REST and/or RESTful applications, but I still do not understand the real meaning of it.

I usually work with the apps which either fetch data via GET or send data via POST to some web service (usually a PHP script) which then either get data from the database or do writing into the database.

Now, is this a RESTful app? If not, what would be a RESTful app? What is difference between RESTful concept and the concept I worked so far with? Please explain via an example.

Also, someone is talking about the REST and someone about RESTful apps. I found that the REST term refers to the theoretical concept, while RESTful is used when we talk about the specific app. Is this right or there are real differences between REST and RESTful apps?

Improve this question
6
  • 1
    If you can build all your Servlets to pull information from GET or POST parameters ONLY (absolutely nothing saved locally prior to the call), then you're properly applying REST. In other words, server plays the role of the model in MVC in that it is not in control but simply uses what's given to perform some task. Hope that explains it a little better.
    – Neil
    Apr 23, 2012 at 8:06
  • @Neil I am on the other side - mobile app. It is a client which uses web service and communicates with it via POST and GET. All web service have been built by someone else and all I did was using them. But terminology confused me. So, If I am using HTTP channel and HttpGet/HttpPost objects, then I am dealing with a RESTful app, right?
    – deviDave
    Apr 23, 2012 at 8:11
  • Not necessarily. There's no way to know if it's a RESTful app if you don't know how the server is done since it might violate some constraints. That said, it's probably RESTful if it returns consistent results.
    – Neil
    Apr 23, 2012 at 9:10
  • @Neil Oh, I get now. RESTful is done on the server. And if I send a post object with a request (not each parameter individually) then it's probably a REST approach. As far as a client (mobile app), it does not care if it's REST or not as coding is the same. Have I got it right?
    – deviDave
    Apr 23, 2012 at 9:14
  • 2
    RESTful is both server and client, but if you can only see the client, than you can only know if the client follows the constraints. That's all I meant. What I mean by REST is, if you need to login, you post username and password. Server validates login and saves user hash key on database and returns it. Now whenever you need to do an operation which requires login, you always pass the user hash key. The server "forgets" that it logged you in, but uses the user hash to validate your login state. If it weren't RESTful, the server would remember you're logged in. Understand the difference?
    – Neil
    Apr 23, 2012 at 9:21

4 Answers 4

Reset to default
14

The key attributes of a RESTful applications are: All communication is via http GET,POST,PUT,DELETE AND all items are addressed via a standard URL of the form http://your.site.com/salesapp/salesperson/0000001/details i.e. only a pure URL with no parameters etc. the URL identifies the thing the GET,POST,PUT,DELETE identifies what you want to do to it.

The main reason for doing this is that you automatically have a stateless service which can be load balanced, failed over etc. etc.

The sheer simplicity of the scheme makes for a very clean interface, totally decoupling the client from any particular back-end implementation.

Improve this answer
5
  • Oh, so far I haven't used PUT or DELETE (mobile apps usually do only GET and POST), but this indeed looks like what I have done and am doing at the moment. It's just that clients did not use REST* terms, but rather "web service" and "php script"
    – deviDave
    Apr 23, 2012 at 8:08
  • 2
    James, Could you explain why query parameters are to be avoided? For example, how do I express that I want the resources filtered in a particular manner without introducing a false hierarchy?
    – Gary
    Apr 24, 2012 at 9:08
  • 3
    @GaryRowe: The URL (with no parameters) identifies the resource you want to manipulate. You can still have parameters but these are not used in identifying the resource. Example a GET on a directory (a URL ending with a /) should return a list of resources in the directory. A parameter on the URL may be used to specify a filter or sort order or something like that.
    – Martin York
    Apr 24, 2012 at 9:16
  • 1
    Thanks, Loki. James might want to edit his answer to reflect that since it appears that he's not allowing query parameters to be used under any circumstances which might be misleading. Actually, there is an interesting observation that the list of resources in a directory is in itself a resource expressing that concept.
    – Gary
    Apr 24, 2012 at 9:26
  • REST doesn't require the app to be URL-based neither does it require you to have verbs like GET, POST, DELETE, etc. However, for an WebApp, URL is the only option and the aforementioned verbs.
    – Nawaz
    Jan 23, 2016 at 16:53
7

REST stands for Representational State Transfer. If your software conforms to the REST Constraints then it is considered to be RESTful.

Right, now that I've shamelessly ripped from Wikipedia, what does this really mean? It effectively means using the inbuilt HTTP commands such as GET, POST, PUT, DELETE and a few other rarer ones to communicate back and forth between a client and server.

What you're doing sounds like its a RESTFul app. However, there's a large difference between well designed and piles o' junk RESTFul web services. For example the PHP code at the other end of the GET might execute state change, which would be considered wrong since a GET is seen as a read only operation. There are subtle differences between how POST (new) and PUT (replace) are used as well.

The Wikipedia article on this is actually really good, so I'll stop here.

Improve this answer
5
  • So far, I used GET (HttpGet) to fetch content and POST (HttpPost) to enter/change content of a database. I sent this as a parameter to HttpPost and PHP script on the web server converted these parameters into SQL code. Is this a RESTful app? I am interested in a concept, not in a how well the PHP script has been done. I haven't made it.
    – deviDave
    Apr 23, 2012 at 8:06
  • 2
    I would investigate the use of PUT in the case where you are replacing content, its more idiomatic REST than always using POST.
    – Martijn Verburg
    Apr 23, 2012 at 8:45
  • Yes, in such case I would use PUT.
    – deviDave
    Apr 23, 2012 at 9:07
  • +1 for noting that GET has to be implemented correctly (i.e. it is idempotent). Such a fundamental error in the early days.
    – Gary
    Apr 24, 2012 at 9:10
  • @deviDave You might also want to look into PATCH which designed for updating part of a resource. As Martin rightly points out PUT is for replacing the entire resource.
    – Gary
    Apr 24, 2012 at 10:20
4

Before going further, this related question may help you

The difference between REST and RESTful is simply semantics. REST is an architectural style applied to a client-server relationship. RESTful is simply a way of telling your clients that you use REST.

Many web applications claim to be RESTful, but actually are only partially conformant to the REST Constraints (as Martijn Verburg has also referenced in his answer). I'll just list them here but I strongly urge you to read the article:

  • Client–server
  • Cacheable
  • Layered system
  • Code on demand (optional)

Since you mention that you work on the client side it might be helpful to see what a REST architecture will give and expect from you as a connecting client. Although REST is not HTTP it is by far the most popular protocol that supports what REST is so I'll frame my example around that.

Your client will be expected to:

  • use HTTP verbs (e.g. GET, POST, PUT, DELETE, OPTIONS, PATCH) to perform relevant operations
  • offer Accept headers and understand Content-Type headers (e.g. you receive some XML you've never seen before but you can use a referenced XSD to create a client-side domain model to present to your user)
  • follow offered links in a Content-Type you understand (e.g. get your user or your application to infer that <link rel="pay" href="http://example.org/orders(1)/payment"> in HTML expresses a state transition to create a payment resource through a POST with a body containing some XML that represents the payment details like credit card number, amount and so on)
  • react correctly to the wide range of HTTP status codes

If it does the above then it can be thought of as being a REST client, you may want to call it a "RESTful app" but that would rather imply that you're using REST on the client side which is incorrect so best to avoid the term.

Improve this answer
3

RESTful means that the interface is a set of objects, that can be read and updated (and possibly deleted). That is there are no multi-parameter queries (only parameter is the object you want to read) and there is only one type of operation that changes anything on the server, upload of new state.

These limitations ensure that all requests are idempotent (sending them multiple times does not have any extra effect to sending them once). This is important, because network may fail anytime and not deliver any request or response and with idempotent requests you just send it again and don't have to do complicated recovery.

Improve this answer
6
  • Upvote for the 1st paragraph. So concise. Thanks!
    – deviDave
    Apr 23, 2012 at 9:08
  • One more thing thou, to see if I got it right. If I (my app) is a client of REST service, I as a client do not case if a service is RESTful or not as my coding is always the same (httpget, httppost, etc.)? This principle matters only to owner of a server script/app?
    – deviDave
    Apr 23, 2012 at 9:16
  • REST is a guideline for designing the semantics of the interface. The underlying technology is HTTP whether the interface is RESTful or not (but other layers like XML-RPC or SOAP are not relevant for RESTful interfaces), so you always use the same httpget, httppost etc. But you handle network failures differently.
    – Jan Hudec
    Apr 23, 2012 at 10:07
  • to add, SMTP is a RESTful interface, though it uses different verbs from GET, PUT etc and a different underlying protocol, the concept is the same - you send idempotent verb based commands to a server.
    – gbjbaanb
    Apr 23, 2012 at 15:25
  • Not all REST requests are idempotent. For example, issuing a POST multiple times will result in a lot of new resources.
    – Gary
    Apr 24, 2012 at 9:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.