When we surf the Web, usually we don’t realize (and we don’t care) where the content comes from or how was it generated. Could be a PHP, Struts, Spring, ASP .NET, Python, Perl generated, connected to a PostgreSQL, MySQL, Oracle, MS SQL Server database. Could be XML, XHTML Strict, HTML 3.2, HTML 4.1 type of document. We just don’t care (well geeks could be curious about, but I’m talking about “normal” people, not us). All what we care is about the information we are looking for.
So that kind of architecture has made of the Web so easy to use and so popular, even when it has lack of several features from the beginning (which we’ve had supplied with tons of extensions and languages). But the point is, it is and will continue being popular. Technologies changes, the way of processing data may have changed, but we always get the content in the same way no matter what’s going on in the basement.
But what about the systems we design or we use for/in our offices or companies? why information and data accessibility seem to be so complicated? The solution may lie in following the Web’s example and learn from it. Okay, so the idea is to offer an interface to get information without having to know how it is generated. Conventional Web Services (SOAP) appears in the scene. It was supposed to be our savior. But it wasn’t. We are still worried about the application and how it works (implementation) instead of focusing on what really matters: information!
It is important to have several representation of the same data so we can access from different (and dynamic) contexts, but we need to know where to go when we need it. So having different names won’t help. No matter what changes in the inside, we still want to access the information in the way we always do. To address and resolve arbitrary resources, retrieve them in different forms and being able to describe them is what we need for our enterprises’ applications.
Resource-Oriented Architectures (ROA) are “marked by a process of issuing logical requests for named resources. These requests are interpreted by some kind of engine and turned into a physical representation of the resource (e.g., HTML page, XML form, JSON object, etc.)” .
In order to manage the information we have REST (Representational State Transfer). Therefore information can be manipulated and represented in different forms in different contexts, and even we can have a cache to avoid the problems caused by a changed WSDL contract. But many people may complain about REST’s restrictions. In my opinion they are more beneficial than detrimental. For instance, the four verbs rule doesn’t cut our wings. If we feel that way, maybe we are not looking into the information and we are focused on the process. That rules exists so we can think about the relationships of the resources and not the process needed to retrieve the data.
So we need to stop thinking only in algorithms, objects, services, etc. and care more about data bringing it to the forefront. But, is it always a good approach? Web seems to support that idea, although we must consider each particular case and evaluate it as unique. Architecture is not about applying a mold over each system we are developing. It is about decisions of design we need to do in order to create structures that will support our growing systems when it becomes necessary.
 Diomidis Spinellis, Georgios Gousios. 2009. Beautiful Architecture: Leading Thinkers Reveal the Hidden Beauty in Software Design. Sebastopol, CA: O’Reilly Media, Inc.