Conclusion
The resource-oriented architecture approach walks a series of fine lines. On the one hand, to initiates of convention, the approaches might seem a little strange and untried. People concerned about their resumes want to stick with tried and true approaches. On the other hand, to those who have studied the Web and its fundamental building blocks, it makes perfect sense and represents the largest, most successful network software architecture ever imagined and implemented. In one light, it requires a radically different way of thinking. In another light, it allows a powerful mechanism for wrapping and reusing existing code, services, and infrastructure with logically named interfaces that do not leak implementation details for many forms of interaction. We have the freedom to be resilient in what we accept on the server without breaking existing clients. We can support new structural forms for the same data over time. We are able to migrate backend implementations without necessarily affecting our clients. Additionally, important properties such as scalability, caching, information-driven access control, and low-ceremony regulatory compliance fall out of these design choices.
Software developers do not usually care about data; they care about algorithms, objects, services, and other constructs such as this. We have some fairly specific recommended blueprints and technologies for our J2EE, .NET, and SOAP-based architectures. Unfortunately, most of these blueprints ignore ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access