The issue is that when you coagulate all the flows of requirements and testable contracts and such, you get programming language artifacts that then become "the service" that you are using. If these artifacts expose a truly RESTful service implementation, then great, but without someone really caring and focusing, they will most likely become RPC like as people move toward "I need to get the job done". These artifacts then become embedded into a "middleware" layer that becomes the point of interface for the service because it's the mechanics of the interface and the services that are provided that are useful, not the "REST" interface. The mechanics of the RESTful implementation might be invaluable to how the service expands and contracts over time, but developers have to deal with using the services, not "designing the services" as time wears on...
Gregg Wonderly Alexander Johannesen wrote: > Heh, > > The only thing that didn't make sense was Steve thinking he was a > heretic. :) > > There's always been a semantic wall between those who push pure REST > and those who push some implementation of it. I like the idea of an > architectural framework for doing things RESTfully, but I don't see it > as something that fits into the middleware; to me, if clients and > servers are RESTful, your job is done. In fact for me, REST eradicates > most needs for middleware, and I suspect this might be why some push > REST back into middleware (either through staying alive or lack of > understanding), but that's just pure speculation. > > Alex > -- > Project Wrangler, SOA, Information Alchemist, UX, RESTafarian, Topic Maps > --- http://shelter.nu/blog/ <http://shelter.nu/blog/> > ---------------------------------------------- > ------------------ http://www.google.com/profiles/alexander.johannesen > <http://www.google.com/profiles/alexander.johannesen> --- > >
