[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: [rest-discuss] Objects at REST...
Daniel suggests: > otherwise we treat methods as subordinate URLs of > the parent objects (e.g. /articles/1/publish()), but it only accepts > GET (we return a representation to fill the parameters and submit it, > usually is a xhtml form but it can be something else for other > media-types) and POST for invocation responding with redirect. It will > emphasize not using RPC style methods but if you must it should use > safe semantics. That's the start of a very slippery slope. You're basically encouraging the OO folks to tunnel RPC over HTTP. I think we've had enough discussions of why that is not such a good idea on the rest forums already. But you just proved my point...thanks! > Obviously I'm biased for it but I think it's a good way to develop an > application, because the user's interface will map the domain model. That doesn't work in the world of machine to machine communications, since it is rare that disparate systems have common domain or object models. The better approach in that scenario is to design a data representation format that is better suited to the integration and transmission of information, rather than cater to internal implementation models on both sides. > As we can use URIs to identify objects we can save those in other > systems, so we are planning to use URIs for every inter application > references, which lends itself to very easy integration. I beg to differ. Common/consistent URI's are a help, but a properly designed data representation, with concomittent semantic definitions, independent of back end domain/object models is what makes integration easier, though even at the best of times, integration is still hard. > Also if the > only interface to your app is via REST, everything can be an WS > without additional effort. What you're doing isn't REST for the most part. It's using HTTP as a transport mechanism for RPC and inter-object distributed communications. It's also great because you think much more > about your domain and don't worry with user interfaces, because this > problem is solved, so essentially you know that in the interface you > can just navigate via URIs and find what do you want (e.g. > /authors/Joe_Blogger/posts?published=false) which makes much easier to > write ajax widgets in the app without up front design. You are mixing metaphors. Integration is not an Ajax-based activity (usually), since Ajax is geared towards user UIs, not machine to machine integration, the latter being the much harder problem to solve, and providing much more benefit when it is solved (think healthcare for a good example of this). Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
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
|