I'm happy to read comments that indicate that understanding of REST is starting to improve. The old adage about sex applies to REST: "Most people that say they are doing it, aren't doing it. Those that are are probably doing it wrong".
It might be best to preface this with a list of things that REST isn't. Rest is not:
1. Pretty urls from your framework of choice that look like /dogs/breed/chow/weight/150 . Why? because the query string exists for a reason and has well defined semantics.
2. Using some framework serialization package to output xml or json for content negotiations. Why? because the hardest, most important part of REST is defining media types, and the garbage spewn by most serialization frameworks is not a clean media type.
3. Clients which access API's by curl'ing example.com/products/$productID are not restful. Why? because RESTful resources should be discoverable using hypertext. A client with a hard-coded url template is not a RESTful client.
REST, real REST, is a great architecture. In fact it's fair to say that the best example of RESTful architecture is the web you see in your browser. API's are usually a shallow copycat. What makes plain old html pages a poster child for REST? I'm glad you asked.
1. Hyper text. Guess what, JSON doesn't provide hypertext. JSON ootb is not restful. Certain standards on top of JSON (like the _link attribute) help bridge the gap. Our friends HTML and XML support hyper text. HTML in the standard way, and XML with the link attribute. If you're not using a content-type with well-defined semantics for links, you're not using REST.
2. Choices for intelligent UA's to browse or present as choices to their users. Forms provide a RESTful way to give a user a choice and allow them to manipulate or browser resources. JSON doesn't have anything like forms builtin. If I can't browse your "restful" API with my browser, you're not using REST.
the list goes on. But don't worry about it. Aside from not being quite as hip, it's perfectly ok if you're app isn't RESTful. Does your app provide a service that performs an action for the user? Maybe it's ok for that to be RPC. Does your app need to be tooling friendly for enterprise folks? It's ok to give them something SOAP related to make it easy for them to integrate their clients. Does your app do some sort of low-level file synchronization like dropbox? Then by all means run your service over HTTP so you can get through firewalls, but nobody cares if you pass back a list of binary identifiers instead of hyperlinks.
Really all that matters is that from a usability perspective, it's nice to make accessing your API easy, and HTTP is a great way to go if you want to lower the barrier to entry in using your API. Don't worry if your API doesn't use "hypertext as the engine of state" if it doesn't make sense for you. When you need to enhance your API, think of doing it the RESTful way first.
You are right, and I also am glad that people come around from their earlier ignorance.
I wish to amend #1. There exists a clever hack that allows any media type to have hyperlinks. Let's take text/vcard as an example, it's a nice existing standard that can be used as representation for, say, a user. (Let's ignore for a moment that a special XML serialisation and the XFN microformat exists, so that the vcard semantics are embeddable into HTML.) It can be augmented with RFC 5988 Link headers:
You see, this works for any resource even when the format traditionally has no (inline) hyperlinks, e.g. image/gif. I also like to replicate inline links as a Link header because it allows an UA to traverse resources with the HEAD method alone.
It might be best to preface this with a list of things that REST isn't. Rest is not:
1. Pretty urls from your framework of choice that look like /dogs/breed/chow/weight/150 . Why? because the query string exists for a reason and has well defined semantics. 2. Using some framework serialization package to output xml or json for content negotiations. Why? because the hardest, most important part of REST is defining media types, and the garbage spewn by most serialization frameworks is not a clean media type. 3. Clients which access API's by curl'ing example.com/products/$productID are not restful. Why? because RESTful resources should be discoverable using hypertext. A client with a hard-coded url template is not a RESTful client.
REST, real REST, is a great architecture. In fact it's fair to say that the best example of RESTful architecture is the web you see in your browser. API's are usually a shallow copycat. What makes plain old html pages a poster child for REST? I'm glad you asked.
1. Hyper text. Guess what, JSON doesn't provide hypertext. JSON ootb is not restful. Certain standards on top of JSON (like the _link attribute) help bridge the gap. Our friends HTML and XML support hyper text. HTML in the standard way, and XML with the link attribute. If you're not using a content-type with well-defined semantics for links, you're not using REST.
2. Choices for intelligent UA's to browse or present as choices to their users. Forms provide a RESTful way to give a user a choice and allow them to manipulate or browser resources. JSON doesn't have anything like forms builtin. If I can't browse your "restful" API with my browser, you're not using REST.
the list goes on. But don't worry about it. Aside from not being quite as hip, it's perfectly ok if you're app isn't RESTful. Does your app provide a service that performs an action for the user? Maybe it's ok for that to be RPC. Does your app need to be tooling friendly for enterprise folks? It's ok to give them something SOAP related to make it easy for them to integrate their clients. Does your app do some sort of low-level file synchronization like dropbox? Then by all means run your service over HTTP so you can get through firewalls, but nobody cares if you pass back a list of binary identifiers instead of hyperlinks.
Really all that matters is that from a usability perspective, it's nice to make accessing your API easy, and HTTP is a great way to go if you want to lower the barrier to entry in using your API. Don't worry if your API doesn't use "hypertext as the engine of state" if it doesn't make sense for you. When you need to enhance your API, think of doing it the RESTful way first.