In the "high" (stringent REST style) REST world, four atomic HTTP methods (POST/DELETE/PUT/GET) are used to do Create/Delete/Update/Select on resources at the server. Each resource has a static URI like "http://www.store.com/product/12345" rather than a dynamic one like "http://www.store.com/product?id=12345". This is why I say REST seems to be pure, clear and simple.
Why REST? Here're claimed benefits (from wiki) :
- Provides improved response time and reduced server load due to its support for the caching of representations
- Improves server scalability by reducing the need to maintain session state. This means that different servers can be used to handle different requests in a session
- Requires less client-side software to be written than other approaches, because a single browser can access any application and any resource
- Depends less on vendor software and mechanisms which layer additional messaging frameworks on top of HTTP
- Provides equivalent functionality when compared to alternative approaches to communication
- Does not require a separate resource discovery mechanism, due to the use of hyperlinks in representations
- Provides better long-term compatibility and evolvability characteristics than RPC
Mainstream tech like Java and .NET announces develop supports for REST, you can get some info from javaeye and WCF Tools China Team Blog. To Java programmers, they can enjoy no-scratch REST experience with Netbeans. But before settling down to work, I suggest you read some dissertations (A Brief Introduction to REST, Architectural Styles and the Design of Network-based Software Architectures) and understand the style, then make a demo using IDE, read auto-generated code to know the programming pattern (entity transform, url resolve, etc.), then adjust your design to adapt REST —— I am doing all these now.
没有评论:
发表评论