Let me be upfront: I love the RESTful constraints for network-based software applications, especially when they cross organizational boundaries.

That being said, I find that RESTful constraints go against business requirements laid out by people above me:

  • "No, we need to keep client state on the server to keep the client lean."
  • "No, we can't use hypermedia, because why don't we just return all the records all the time for the data we need."
  • "No, we can't make the client make different requests, we have to make it easy for them."

Could the downfall of the RESTful approach's adoption in software teams be the need for more intelligent clients?

  • Please provide a reason when downvoting.
    – edev
    Commented Aug 10, 2016 at 8:41
  • 1
    I didn't downvote, but the question is more about how to deal with difficult people you work with, rather than any technical issue about REST.
    – paj28
    Commented Aug 10, 2016 at 8:46
  • 1
    That's an interesting perspective. Perhaps I'm being too reasonable, but I don't think these people are being especially difficult, they're simply not "bought in" to REST at a technical level, although they see the benefit in "services". It's an adoption problem, either the people or the technology, I'm not sure :)
    – edev
    Commented Aug 10, 2016 at 9:25
  • Proper REST is complex and subtle. You can't use it effectively without a complex generic REST client library, which are rare. In my experience most developers buy into the "simple JSON+HTTP API with stateless servers" not into REST. Quite similar to how most developers only use XML for its syntax, ignoring DTDs, namespaces and all the complex parts. Commented Aug 10, 2016 at 9:34
  • Thanks for sharing your experience. In my current role, I haven't gotten as far as convincing colleagues with stateless servers.
    – edev
    Commented Aug 10, 2016 at 9:37

1 Answer 1



The most common use case for implementing web services nowadays is to provide a JSON API to a client program. What tangible benefits does full-blown REST provide to a JSON API that a simple GET and POST API (or even just POST) doesn't already provide in a simpler fashion?

To put it another way, if REST is so great, why don't we use REST everywhere? Why not just write all of our class methods following REST semantics as well?

Hypothetically, I could create a JSON API whose semantics is to match up with a controller method on the server. That method could be anything, and it could take any number of parameters. I decide that my rule of thumb will be to use GET for methods that return a value, and POST for methods that do not. That's clearly not REST semantics, but it's perfectly sensible from a design perspective.

HTTP has some quirks about it that can make it difficult to line up an application's API semantics with it. For example, I can use form parameters with POST, but not GET. That makes a good case for simply using POST everywhere, if your only goal is to implement an API that a client program can talk to that is as simple and straightforward as possible.

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