I think in an ideal world most developers would want to do things the right way. That means having (a) the time to do it all and (b) the knowledge to know exactly how to attack it.
In the real world though not many of us know exactly the right way to do all of REST correctly (admission - I don’t) and then there are the commercial pressures that are brought to bear - some aspects may not be required, time is money, and you have functional requirements to satisfy and a hard limit on the total expenditure (time, money, people etc). So people do the best they can and implement what they need. Of course they’re going to call it REST if they think it is REST, in the same way that many teams will say they are agile when they might only implement a small sub-set of what being completely agile actually is. If you are going to have to fight to make change then prioritise the aspects of the implementation which provide the most benefits - be it architecturally, efficiency or simplicity. Then you can sell your changes to your peers with solid arguments to back up why they should adopt the changes. -- You received this message because you are subscribed to the Google Groups "Java Posse" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/javaposse. For more options, visit https://groups.google.com/groups/opt_out.
