Commenting on Tim Bray’s blog post about the use of Post for REST, I came to a discussion about actually how much RESTFull is an API, and more specifically if it should be RESTFull at all.

You see, many people is trying to get their APIs into the REST world, and some people like Dilip Krishnan believe the reason is to gain "simplicity, discoverability and serendipitous reuse of the solution". Still, as I read through all the comments on how to "imagine" the app so it fits REST, I feel a greater sense of something not right about it.

When creating a solution, you may want to analyze first the functional requirements, and then the quality properties. The ones noted by Dilip are great, but I’m not sure all apps that hit the web every day need to accomplish them. Furthermore, REST is not the only way of getting those attributes! Let’s explain a little what this famous style is so you can understand what I’m saying.

The REpresentational State Transfer style was born as an architectural style to represent/improve the modern web implementation, as Roy Fielding explains in his dissertation. So, REST is an architectural style, and that means it has a set of constrains that the app needs to adopt to obtain the benefits. But that architectural style is not built from scratch. It is built by composing several other well known styles like Client-Cache-Stateless-Server, Layered-Client-Server or Code-On-Demand. Any of those can be used separately and all their pros and cons will be cast upon the solution.

Now, this is a special case where an implementation is taken as a base to develop an architectural style that improves it. Usually, you have a solution to build with a set of requirements, and you look for an style that better fit into the problem. But once you start changing the problem just to adjust to an architectural style, you are actually “Wagging the Dog” there. And it seems to be a contagious syndrome.

So, what does it need to have an APP to be worthy enough to use the style? Well, first

• - the semantics should be the ones of the style.
• - Next, the app should try to solve a similar issue the style is solving, and third,
• - the app’s quality attributes should be the ones the style is promoting.

If some of the three is not true for your app, and you still want to use the style, I may guess you are trying to get the buzzword title instead of the real benefits.

One little clarification at this point: The web is one implementation that follows the style, it is NOT REST itself. What do I mean by that? Creating an app that runs on the web doesn’t make it RESTFull. Using HTTP for your API won’t make it either (I wanted to clarify it since all comments are about HTTP and its semantics and it seems everybody confuses the implementation with the style). You need to read the dissertation to learn all the constrains, but even more important, to learn if the style is for you or not. You may learn HTTP is not a required protocol, but one constructed that meets the constrains. You can build your own! (and make it standard).

William Martinez.

Neal Ford from ThoughtWorks, recently wrote an article that is the first of a series related to architecturing and design called Evolutionary Architecture and Emergent Design. The first article is a revisit to the architecture and design concepts. In it, Neal describes the evolutionary architecture with these lines:

However, just because you can't allow architecture to emerge doesn't mean that it can't evolve. If you have created a flexible architecture and taken care not to create an irreversible decision, you can allow it to evolve over time as new concerns appear.

Let's talk about that idea...

Pages: 1 · 2 · 3

Hello!

Back from a long time. And that is because there is a new baby at home, our first!

Say hello to Juan Pablo, from now on part of my life.
Oh, Fatherhood... that is a great adventure...

William.

This is a quick post to notify all people out there that there seems to be a lot of people confused about the real meaning of the terms in the title. Let’s see:

Ajax is not a graphical technique. Surprised? Well, it never was. I see lots of Ajax frameworks out there providing graphical gadgets/components and people believe Ajax is just a way to mimic desktop look and feel in the browser.

Ajax was born to be a way of having asynchronous calls to the server, that is without the need of a page load for each new data fetch. That data was supposed to be done using XML (now Json is another option), and the call with HTTPRequest object. The data was helpful for lots of things, one of them loading combo boxes on the fly. Of course, the examples were done in UI to show the technique, and later on everybody was confused, thinking Ajax was just a way to make the UI experience richer.

Ah, and there we got Rich Internet Applications. These applications are real richer in user interactivity (think on Gmail). You can create those things using other tools, not necessarily Ajax techniques (yes, Ajax is not a tool nor a framework, but a technique). You can even (at an extreme) have RIA using Javascript and NO AJAX! A simple Flash site can be a RIA with no Ajax. And another Flash site may use Ajax (actionscript also counts) to make things richer.

Lastly, Web 2.0 is not Ajax, nor RIA! Web 2.0 is about people, the web working all the way around. Instead of the site owner posting and all the other mortals reading, web 2.0 says all the other may contribute to the site, create communities, build collective knowledge, be a part of the site! Now, to achieve this, sites can attract people using flashy pages, actual RIAs, and those may use Ajax to implement.

So, when someone says: “Here is the new tool for Web 2.0!” and you read later on it is a RIA tool, and later on that the tools allows to create rich pages using Ajax, you may note that someone does not know what is he talking about.

William Martinez Pomares

Through all these years, the service concept has been a confusing one. At the edge of Service Era, even before the service name was coined, services existed and were implemented using the tools at hand, and the tools helped to define the concept. I mean Services in all their presentations, those including SOA and Web Services, REST and CORBA, etc.

Today, after all this time, hundreds of articles, papers and news had been written explaining all facets of Services. Yet, many of them presented conceptual differences, and in the community’s mind a mix of myths started to grow.

The following is a list of myths I’ve encountered to be still present nowadays. Some are innocuous, some others are not. Furthermore, some may not be considered myths at all for all people, since their opinions may differ from mine. Anyway, here they are.

Myth 1: SOA = Web Services.
More that a myth, this is a general confusion enforced by tool vendors. Why? Because of selling SOA ready tools that offered Web Services construction, so conceptually having SOA was simply achieved by having Web Services
.
Reality: A Service is a bunch of functionality that is cohesively integrated into a locatable resource and accessed through a port using messages. (No, it’s not an object).

SOA is an architecture style that simply indicates the use of Services (special functional units) in the architecture. That is, you can have several very different architectures that are SOAs, with the common characteristic of having services in them.

Web Services Architecture is a special architecture that defines the description, interaction and messaging definition for a service that uses the web to communicate. Note that the service concept is part of both things, but Services are not limited to be Web Services. Web Services is just a way to create services. And Services may not use that architecture, nor be implemented trough the web.

Myth 2: Web Services = RPC.
SOAP (Simple Object Access Protocol) was born to make remote objects accessible through web. Its initial goals were clear: allow to encode a method call through web using XML. Later on, the service definition and concepts were improved, not limiting it to remote object method invocation but to a messaging system (even SOAP acronym changed to Service Oriented Architecture Protocol), but the “traditional” way of doing things kept implementing the services as simple remote method calls. In other words, a simple RPC.

The Service concept states the communication should be using messages, and those are all one way. If you want a request-response behavior, you need two messages: one in-one out. So, at the end, the services concept accepts RPC, but services are not RPC.

Martin Fowler states that difference in the book "Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions (The Addison-Wesley Signature Series) by Gregor Hohpe and Bobby Woolf", when he writes about integration by sharing. RPC is good to share functionality, but services will help to share functionality and data, and they are the less coupled form of integration.

Pages: 1 · 2 · 3