I am, indeed, new to RESTful services and while I feel I understand the concepts I am resistant to some aspects of its use in my current project.
The project involves the provision of some form data from another system. Project members insist that the form data should be broken down into "resources" as there are customer and customer addresses etc on the form.
So its all about how granular the REST API is... the form data is not complete and actionable until we have all of the form data (and there's very little at that). And, in fact, I guess we will have to prepare some integrator on the service side to assemble all of these resource bits before we can use them because at present we have no persistence for them or, specifically, we have persistence for them but need to hide the data before it becomes actionable.
Again, at present this is point to point communications without any business case for sharing or service composition.
So, i'm of the idea that one service "form" using a POST is an acceptable optimization and do to the amount of work it cuts for us is a pragamatic approach.
What am I not getting about doing it the hard and expensive way?
If you don't need a high level definition in which you need to use a heavier structure with a well formed and heavy xml with its dtd, where you would be using a WSDL, etc. Then the best choice is REST, is lighter and use HTTP.
Here you can find a better explanation:
WSDL vs REST Pros and Cons