The main problem I battle with with that you can get around this by having more, finer grained resources which only expose the information they need, and can be secured at that finer grained level, but then you increase the roundtripyness of your system.
This has occasionally led us to keeping more than may be desired in a more general resource, for example say /customer/45 with a lot of data, rather than /customer/45, /customer/45/billingaddresses, /address/1, /address/2, /address/378 as separate resources, incurring 1+n calls to the server, 1+n transactions/auth checks etc. mark -- "Great artists are extremely selfish and arrogant things" — Steven Wilson, Porcupine Tree 2010/11/1 Cédric Beust ♔ <[email protected]> > Is it any surprise that this leads to the exposure of internal > implementation details? > -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
