What is RESTful application?

Question

There has been a lot of hype over REST last few years, and I've tried to embrace the principle and understand it's benefits. Some things about REST still elude me, though. I'll try to be concise and to the point:

• Can a web application be considered RESTful? What are the benefits of this? I can understand (to a point) advantages of RESTful service, which is to be used by many clients, but what is gained by using REST principles when developing application interface which is to be consumed by HTML/JS frontend?
• REST mandates use of verbs which roughly map to CRUD operations and to which the server responds with representations which in turn put client in a new state. Does this imply that ALL actions on a resource must be done through modification/creation/deletion of that and possibly many other related resources? What about "atomicity" of such operations (i.e. transactions)?
• REST compliant service is supposed to be self-descriptive (through HATEOAS principle), but the lack of metadata makes it impossible for a client to e.g. create a resource without knowing exactly what fields (and their types) are mandatory. This information must still be provided out-of-band. Is there something I'm missing here?

I could come up with more questions, but it will be enough for now if someone could clarify these points for me.

Answer 1

Some notes about your questions:

1) If your web application is a Single Page Application the simplest way to communicate with the server will be if it is a Rest service.

For a traditional web application I think is better that "controllers" communicate with a service layer using dependency injection.

3) Yes, of course the client needs to know the format of the data it is receiving. But AFAIK, Rest does not give any constrain about how this metadata has to be defined or transmitted.

The HATEOAS principle refers more to the discovering of related resources from a given one. There exists different conventions to express that relations, see for example: http://stateless.co/hal_specification.html

2) Every Rest action must be atomic. If you need a some kind of long operation, the usual is to create a resource that describes the operation. The state of the operation is retrieved from that resource, and you do whatever you want with the operation (i.e. Cancel it) interacting with that resource. See an example of that here.

Answer 2

1.Usually REST architecture is designed when application is going to be used by different by nature clients(external api consumers, mobile applications etc). In this case development costs will be paid back completely. Developing truly REST application is not such a simple task to do. So, if you know in advance that your application is to be used only by your client-side, probably, you could consider 100% RESTfull approach as an overhead. But it does not mean that you should not design your application well, you still could use some of REST principles in your application. For example, stateless application simplifies scaling, REST-style URLs looks good for users and search engines, etc.

2.Yes, in truly REST all interactions should be expressed via standard verbs on resources. But you could still create Transaction resource to wrap around your transaction. See great discussion here: Transactions in REST?

3.As I understand nothing prevent you from providing metadata-information in HATEOAS-based response.