The way i think about REST is this: here is my stateful application, how can i make it available over HTTP/REST. So i start identifying resources. Most of them are easy - they map to your domains models. But some of the operations on some of the resources are quite important to my application (eg: ordering products, making a payment etc), so i consider creating separate resources for them.
It looks like you are referring to modeling your stateful application when you talk about RESTful thinking.
That's a very good question, what is RESTful thinking?
I personally think so many of us are misguided in our think when it comes to RESTful APIs. In order to make good design decisions for your API you must understand how the users of your API perceive RESTful APIs. In order for you to understand how the users of your API perceive RESTfuls APIs you must consider how the masses (within your target audience) understand RESTful APIs.
Whether your interpretation of RESTful APIs is right or wrong does not matter. What matters is that people can use it. In order for people to use your API it must be easy to understand. In order for it to be easy understand it must be well documented and consistant.
Therefore RESTful API design must be approached on a case by case basis. You must understand your users, their knowledge base, and how capable they are.
wvanbergen: Interesting article. It was thought provoking at the very least.
The way i think about REST is this: here is my stateful application, how can i make it available over HTTP/REST. So i start identifying resources. Most of them are easy - they map to your domains models. But some of the operations on some of the resources are quite important to my application (eg: ordering products, making a payment etc), so i consider creating separate resources for them.
It looks like you are referring to modeling your stateful application when you talk about RESTful thinking.