REST concepts
REST stands for Representational State Transfer. It is an architecture for distributed software systems. Nowadays REST is the most popular architecture when it comes to build software as a service (SaaS) on the web, and the reasons for it are the properties that emerge when the very simple principles of REST are applied.
It is never overstated that REST is an architecture, and that no "implementation" of it exists. What this means is that if the principles of the REST architecture are followed, distributed applications will exhibit some very much desirable proplerties:
History
We owe REST to Roy Fielding, who introduced it in the year 2000 in his doctoral dissertation.The adoption of REST by the major players in the industry (Amazon, Facebook, Google, Twitter), have made it the current de-facto web service architecture.
Principles
Thoughts
Undoubtedly, the best way to start understanding REST is by reading Roy Fielding's doctoral dissertation. It is interesting not only to gain insight about REST, but to understand software architecture as a whole.
REST architecture is no silver bullet. It works really well for applications that handle pure resources like documents, or objects in buckets like Amazon's S3. However there are other more involved services, whose interfaces do not work well with REST. In my opinion if a conceptual effort has to be made in order to fit your systems requirements into a REST architecture, you are better off not using REST. Modern RPC protocols (like json-rpc), are a good solution for these more complex services. However, some of the principles of REST can still be applied, specially statelessness, client-server and the use of layers.
Links
It is never overstated that REST is an architecture, and that no "implementation" of it exists. What this means is that if the principles of the REST architecture are followed, distributed applications will exhibit some very much desirable proplerties:
- Massively Scalable
- Maintainable
- Human managable
- User's perceived performance
- ...
History
We owe REST to Roy Fielding, who introduced it in the year 2000 in his doctoral dissertation.The adoption of REST by the major players in the industry (Amazon, Facebook, Google, Twitter), have made it the current de-facto web service architecture.
Principles
- REST is a client-server architecture
- REST is stateless in nature
- REST takes advantage of caching
- REST uses a uniform interface between components. This common interface is defined by the following constraints:
- identification of resources
- manipulation of resources through representations
- self-descriptive messages
- hypermedia as the engine of application state
- REST is a layered architecture
- Client functionality can be extended by downloading code from the service
Thoughts
Undoubtedly, the best way to start understanding REST is by reading Roy Fielding's doctoral dissertation. It is interesting not only to gain insight about REST, but to understand software architecture as a whole.
REST architecture is no silver bullet. It works really well for applications that handle pure resources like documents, or objects in buckets like Amazon's S3. However there are other more involved services, whose interfaces do not work well with REST. In my opinion if a conceptual effort has to be made in order to fit your systems requirements into a REST architecture, you are better off not using REST. Modern RPC protocols (like json-rpc), are a good solution for these more complex services. However, some of the principles of REST can still be applied, specially statelessness, client-server and the use of layers.
Links
enviado por julitopower el 10:04 AM
Suggestions (sugerencias):