[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Evaluating RPC versus REST
> From: Paul Prescod [mailto:paul@p...] <snip/> > I think that I want to emphasize Mark Baker's point about constraints, > with a quote from the dissertation: > > "There are two common perspectives on the process of architectural > design, whether it be for buildings or for software. The > first is that a > designer starts with nothing--a blank slate, whiteboard, or drawing > board--and builds-up an architecture from familiar components until it > satisfies the needs of the intended system. The second is that a > designer starts with the system needs as a whole, without constraints, > and then incrementally identifies and applies constraints to > elements of > the system in order to differentiate the design space and allow the > forces that influence system behavior to flow naturally, in > harmony with > the system. Where the first emphasizes creativity and > unbounded vision, > the second emphasizes restraint and understanding of the > system context. > REST has been developed using the latter process." I find this to be an interesting quote. It seems to me that in the field of enterprise application development, there has been a clear trend toward this second approach. J2EE strikes me as a good example of this. J2EE defines an architectural framework that compels the implementor to implement *managed* components, with the framework defining how that component interacts with key infrastructural services (for naming, transaction management, lifecycle management of components, etc.). Before J2EE, many OO frameworks adopted similar approaches. The intent seems to be to take certain infrastructural aspects of applications that can be generalized, and incorporate them into frameworks that implement proven, best-practices approaches, releaving the business developer of having to think of these aspects (and potentially stumbling over them) and to focus more on business logic. These also seem intended to permit the deployment and use of shared, generalized services that can apply consistent policies across the enterprise (and beyond?). J2EE is API-centric, though; not protocol-centric. For web development, the APIs generally [expletive deleted] and have never achieved a similar level of sophistication. The most they tend to offer is cookie-based session and some template technology, then you're on your own from there. (There have been some interesting attempts to offer richer frameworks, such as Cocoon. I'm not familiar enough with these alternatives to judge how much the facilitate the "resource modelling" part of the app, though.) The thought of an API-centric framework explicitly architected for modelling an application as REST resources strikes me as something that could really raise the level of web development. I wish I had more free time to work on such a thing.
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|