REST (Representational State Transfer) is a trendy design pattern for (Web-)APIs. Many developers use REST over other concepts for their application, mostly not considering the potential downsides.
When you think about implementing a REST-API, read this article first, so you consider these two essential issues that come with REST:
Many developers do not realise that a pure-blooded REST application (in the sense of Roy Fielding’s spec) does not store a single kind of state on the server(s). This has many advantages due to scalability (e.g. simply scale out a load-balanced REST-application from 10 to 1,000 servers – network overload due to huge requests as well as data layer scalability is not considered here). But there is a very common use case, where there has to be a state on the server-side: Authentication.
Most of the common authentication mechanisms require server-side statefulness and are therefore not compatible with REST in its proper sense (There are approaches for stateless authentication, but they can lead to considerable security flaws). Authentication leads to a degeneration from a REST- to a RESTful API.
SOAP provides the possibility of ACID transactions. REST does not come with any ACID transaction mechanisms by design (relates to HTTP), so it is not possible to group REST requests to a logical unit (having the ACID property). Critical hit. REST is K.O. in the context of applications requiring ACID transactions (or imagine the case where you don’t think you need ACID for an application design, build a REST-API and, after a few years, you realise that you have to change your whole API).
This should not be a “hate post” against REST, but developers & architects should keep in mind those two little facts.
If you want to read more about the REST hype, check out this talk.