--- In [email protected], "Anne Thomas Manes" <[EMAIL PROTECTED]> wrote: > > Let me reiterate. REST is about the way you design/implement a > capability (i.e., a service). If you abide by the REST constraints, > your service will exhibit a number of desirable characteristics, such > as simplicity, scalability, performance, reliability, evolvability, > maintainability, visibility, and portability.
Oh come on, Anne! Aren't you overstating the case just a little bit here? I hope Burton Group clients receive somewhat more thoughtful analysis than this! Surely these "non functional" aspects of a service will depend mostly on how the service is *implemented*, for which the REST constraints provide no guidance. If I model my resources poorly, or code my services badly and using inefficient programming techniques, the services will not exhibit any of the qualities you suggest, despite my conformance to all of the REST principles. To expect otherwise is about as silly as thinking that just because I define similar attributes of a service using WS-Policy, or even store these in a SOA registry, that this will ensure that my service implementation will actually *meet* the declared requirements. The success of any WS/SOA or REST initiative is still reliant on good quality engineering practice. The adoption challenge for both is to find ways to bring this within reach of the average developer and IT organisation. This might be done through tools, patterns, documented best practices or otherwise. Regards, -Mike Glendinning.
