Congrats !!!

What is missing, on the other hand, is a general purpose agent programming model that allows the easy expression and construction of hypermedia-consuming, goal-driven applications.

Let's be polite and argue that there are many simpler problems we need to solve before we tackle that one. So, allow me to write the response I expected from him.

First, I would have like to see Stu's model of REST. I am not sure you can just stumble upon the kind of programming model he is talking about. It has to be "designed". So, since Stu understands actions and resource lifecycles, he could have at least articulated how they fit in REST, since no one is talking about the "uniform interface" any longer, it would have been timely to establish that once and for all. It would for sure limit the amount of CRUD being generated.

So, allow me to offer, what I think REST could have been (actually is):

There are 3 RESTs out there. Roy's REST or REST Core. That's not very useful by itself as a programming model. Then there is the practical REST which adds queries (with properties) and collections. That's the CRUD of REST. The "Full REST" has actions and events. How do actions relate to a resource? Their invocation triggers a transition from one state of the resource to the next. These concepts have been on the table since the 60s. But in 2010, we are still debating about it. WOA ! That is called progress.

How are actions expressed in the full REST? Quite simply, RESTafarians do that every day: you just transform a verb into POST + noun. For instance you want to pay a bill, you POST a payment to the Bill resource. Yeap, that easy, in French this is called "encoding". I am glad ThoughtWorks charges you $300 an hour to teach you this kind of thing, this is as close as printing money as it can be.

So, in case you still wonder, no, an interface to a resource is not uniform, far from it -even Jim and Savas finally got that after 3 painful years-, no, CRUD is not the way to go, and no, people that tell you "Data Services work", have no idea what they are talking about. Sorry. If it is not clear to everyone, a CRUD based programming model forces you to push "reusable" business logic on the client of the resource, creating large levels of redundancy, not to mention that hardly anyone will let the state of their resources be decided on the client. For those of you that still don't know what REST means, it stands for REpresentational State Transfer, not for REsource Data Access. A representation of the state of the resource is passed to the client which indicates the actions he or she can take. Brilliant, Roy's REST is brilliant, he never claimed that what you needed was a bunch of CRUD.

That's why Actions work so well with hypermedia, actions are embedded in resource representations, this actually happens billions of times a day on traditional web pages. But mysteriously, the RESTafarians did not notice it, unless they don't want to "talk" about it (Stu?). I mean in the Cloud even Tim Bray finally figured out that indeed there were actions like "start or stop a server", how about "reboot a server". He even figured out, by himself, that you can't CRUD those actions.

This little action "secret" is an inconvenient truth because the RESTafarians precisely sold you on the idea that "contracts" did not exist: all this XML Schema and WSDL crap was just here to jack up the price of consulting engagements and that they will save the world by ridding it of these pesky contracts. If that is not boloney, what is Stu? But I digress. Let's go back to the main problem: REST Versioning.

Before I continue on, I want to reiterate why versioning is so important in connected systems. It is really important because you can't predict the future. Yes, you can't build an asset today with the expectation that in 3 years someone will come around and consume that asset as is. It might happen less than 1% of the time. Don't waste your time designing for that or Dino Buzzati will end up writing a book about it. So, how do you go about versioning in a connected system? It's quite simple. It is not the new consumers who "reuse" the old service. It is the old consumers who can still operate with the "new version of the service". Reuse happens the other way around. This is what is called "Forwards Compatible Versioning" because it is different from "Backwards Compatible". Backwards compatibility happens when you change the consumer and it can still talk to the old service. Versioning is the reason why RPC failed, this where CORBA failed, this is where JEE failed. This is where Spring fails. Versioning is actually such an acute problem even in monolithic programming models that people had to invent new technologies like OSGi to deal with it in  OO. I am glad that people like Dave Chappell are paid thousands of dollars per hour to claim that "SOA is a failure", that "Data Services are the only things that work" and all that because you can't predict the future.. What a gig.

Kjell and I wrote an article on how "Forwards Versioning" works in Web Services. I would recommend you take a look at it if you are not familiar with the concept.

So, now that we have a full model of REST, what can be versioned and how does it work? How different is it from Web Services?

Well, there is a lot that can change in a REST-based information system. Let's review the use cases one by one.

Check, Check, Check, just like Stu predicted, Web Services forwards compatible versioning foundation came from the W3C so it works for REST as well. It actually works even better than Web Services because you don't even waste time updating a contract. You just create a new URI syntax, you email it to the new consumers and voila.

I forgot something? What did I forget? Ah, a small detail. You remember, I keep saying "REST couples access and identity". Such a small little detail. It means that the business logic behind a GET ResourceRepresentation or a POST Noun is bolted to the URI. So when I say "GET /customers/123" I am bolted to a piece of code annotated with the innovative JAX-RS notations. That's a problem because /customers/123, as Stu explains it, is also an identity, a foreign key to somebody else. So I can't change it (remember cool URIs don't change). How do I go around that? Pete Williams provided a work around using media types. Usually Media types are used for content negotiation, he suggests to create a media type per content type, per version. It works. We know how well people are going to keep track of their media types and versions.  Just try to submit these types to the IANA ...

Does that work for POST + noun? It could. But, it is also safe to use a URI syntax because a POST of a resource to /customers/123/payments is actually an operation of a service end point, REST allows the server to append the payments in a different locations, so it would be quite ok to POST at /customers/123/payments/v1 and at /customers/123/payments/v2. The payments though would all be under /customers/123/payments/

So yes, versioning kind of works. Are we done? No, there is still another detail missing: the unit of versioning. Yes "real-world" resources have complex lifecycles and often composite states. Each composite state/lifecycle corresponds to a unit of versioning. Unfortunately in REST, there is no "unit of versioning". As you have seen, you add stuff here and there and before you know it you lost track completely of what exactly you are versioning. The key problem is that your business logic for a single resource could potentially be dangling off dozens of endpoints. So you have to painfully manage all these annotations in a forwards compatible way. I am not sure that is less work than creating a WSDL. In REST, there is not even a trace of the beginning of a "unit of versioning" beyond the URI itself. I will let you compare that with the elegance of versioning with Web Services contracts where you can replace the the business logic layer at the change of an endpoint and assemble different WSDLs for the same service and different consumers based on what you want them to understand. As a matter of fact the key design pattern in SOA is the separation between the interface and the implementation? So what do the RESTafarians argue about? They want you to bolt the interface to the implementation. They even create annotations to make sure you'll never set free from this architectural atrocity. It's like designing a house with the bathroom behind the front door. RPC, CORBA, JEE all bolted the interface to the implementation. Somehow, Web Services escaped that fate. But the old CORBA guys couldn't live with it. They actually want the interface to be directly generated from the code.

Did I talk about bi-directional interfaces? Ah yes, REST can't do bi-directional interfaces either. HTTP can, but not REST.

So Stu, I am sorry, a million times sorry. You'll retire before you can build a decent programming model on top of REST. In the meantime, you are creating a spaghetti plate at the scale of the Web. The RESTafarians, have simply have no idea about what it means to build an information system, and I am sorry, but I think you belong to that category. You have given no evidence of a basic programming model and please let's not even talk about CRUD.

So I am sorry, REST as a programming model, REST as middleware, the (other) REST as I call it (to make it clear nothing that I say here applies to Roy's REST), that REST is fraud, a massive fraud, imposing billions and billions of lost productivity in IT, setting us back 10-15 years, and I wish, Stu, that you would either tell people to hold on, until you figure it out, or if you already came to the same conclusion that you would be open to speak about it.

I no longer think that Domain DSL make much sense. Domain experts rarely have the semantic precision that would allow supporting their work with a DSL. Note that technical people don't exhibit much more precision. Just look at the REST space and see how people "interpret" the semantics of a resource, four verbs and URI. Ok, maybe the problem is that REST is so poor semantically that they "have to" add their own semantics, but still.

Recommendation 1: build your language for the solution space, leave the problem space to creative expression.

On the contrary, I would argue that the problem of limited expressiveness is precisely the explosion of "interpretations" of semantics. Again, use REST as an example: everyone needed a query language. What happened? everyone created his/her own. It may not happen on the same scale in your organization, but it will happen enough to be a real pain.

Recommendation 2: Make your language as expressive as it is needed but not more

Text is beautiful. Do not mix the need for graphical visualization with the need for graphical design. Most often textual definitions can be converted (automatically) in graphics.

Recommendation 3: use graphical editors as rarely as you can. Prefer textual notations with graphical renditions

The goal is not to have everyone express something, the goal is to build solutions fast. The design of the language must be driven by how fast you can translate requirements into a working solution. Take the example of BPMN. BPMN was designed to let a certain category of people express their view point. That's great. When it comes to create "executable BPMN definitions", well the little known secret is that developers stuff the definitions with tons of arcane, hard to debug, scripts. This is highly inefficient. From my own experience, it can take 3-5 times as much to write a solution using an executable BPMN engine than writing it in 3GL.

Recommendation 4: design the language for rapidly building solutions (from as few viewpoints as possible) 

In MOP this best practice translates as rules that enable execution elements to control the lifecycle of other elements. The language needs to be one, however, you should restrict with precision the lifecycle operations a model element can invoke on another. I would not call that partitioning

Recommendation 5: understand with precision which model element control the lifecycle of other model elements

This is a difficult topic, MOP doesn't necessary help here. However, because MOP forces you to think through the entire lifecycle of the model elements and the relationships between the model elements at the implementation level, you may end up needing far fewer evolutions. DSL focuses only on the associations between model elements, not there interelated lifecycles.

Recommendation 6: Think through the entire design of the language, especially the lifecycles

We agree, yet, as you focus on the solution side, you should remain as generic as you can, what is wrong is the monadism of general purpose languages, not genericity per say.

Recommendation 7: Think polyadic programming languages

I would say, learn from both 3GLs and DSL. This is what MOP is about, bringing cogency and polyadism together in one efficient formalism.

Recommendation 7: Design Cogent Polyadic languages

You don't have to choose, this is the wrong choice. DSL forces you through that choice because second class citizens are created to implement the cogent aspects of the model. MOP focuses on first class citizens without the need of artificial model elements needed to express execution elements.

Recommendation 8: Avoid creating model elements to express execution semantics

I have mixed feelings about that one. Why would you create libraries and patterns in your DSL? They exist only because of the monadism of the general purpose languages. Programming Patterns would have never existed if programming languages were polyadic.

Recommendation 9: Rely on as few libraries and patterns as possible on top of your language, prefer a higher degree of polyadism

Go Textual !!!!!!!

Recommendation 10: MOP is textual in nature, structure your language to facilitate teamwork and leverage all the source-based tools

The bad reputation of Code Generation is due to the lack of execution semantics in DSL, i.e. DSLs are not cogent. MOP languages facilitate the transformation (not generation) into general purpose languages because the execution semantics are half way there.

Recommendation 11: Prefer "transformation" to model interpretation or code generation

Yes, but you can modify "transformed" code. Round-trip engineering in code generation can be very tricky. However, using a transformation paradigm in lieu of code generation make the round-tripping a lot easier.

Recommendation 12: You may use round-tripping safely when it makes sense, but avoid it if you can

I am not quite sure today, why the DSL community do not see how much simpler their life would be by making DSL cogents. I also don't see why the general purpose language guys keep annotating their language to death. They annotate it so much that they can't see the semantics behind their annotation. But, hey, what do I know? I am just a MOPer.

1. Standards sucks and are ever changing, they don't fit with each other or offer some kind of upward compatibility
2. REST is not as "easy" as some people would like others to believe it is
3. Innovation in 2010 is no free lunch, lots of people who don't understand a thing about innovation get in the way for various reason (greed, fud, ego...) and the innovators have to deal day in and day out with their stupid goals and constrains, not to mention unsustainable ROI

Thank you Lori. It's refreshing that someone is not talking about the Lalaland of XYZ and is not afraid of using "real" words, not to mention avoid bolonizing their readers. There are so few like you that it is worth mentioning.

Your post is also terrifying because it leaves little hope to achieve building anything right. Actually, the probability to get the right thing accomplished is as high as winning the lottery. In many ways, I agree with you. When you see products like the iPhone and you think at the alignment of technologies that needed to happen to realize such a device, only a strong culture and "proprietarism" can deliver any kind of innovation today. Standards are the wrong approach to innovation. They kill innovation. Pretending innovation is easy is the biggest lie of the 21st century. No, innovation is complex and requires a bunch of smart people working together without just ROI, greed, or fear as a driver. I think the next decade will see the emergence of new winners who understand innovation at that level. Of course, there are counter examples to my argument, company like WSO2 have innovated on top of less than optimal standards, but I think they remain the exception, and it is probably due to their strong culture and sense of values.

Stu also provided a follow up to my challenge to define a version strategy. Don't get me wrong, I like Stu, he is incredibly competent and he backs his work with a long experience. But, Stu failed to provide a compelling strategy for versioning. He actually admits that:

In a RESTful approach, URIs are your "foreign keys", and if you embed a version identifier in them, they need to change when you upgrade to the next version if you embed those versions in the URI. Assuming you can't convince your resource owners to use languages with version identifiers as a MIME parameter or inside the language itself, how is that done? 

 This is what I mean by REST couples access and identity.

Stu also conveniently forgets to speak about the "unit of versioning". Nearly every resource is participating in different lifecycles. A resource has different states, composite states. Each lifecycle has a set of actions (which are always encoded as POST+noun in REST). This is the unit of versioning. A comment from Mike actually speaks to that very problem:

there are many times when an application-flow update requires support for side-by-side versioning

Yeah, the RESTafarians finally touch the real problems or building real systems, not just blog posts and plain vanilla articles or useless annotations. I actually argue that without the visibility of an explicit lifecycle, these problems are impossible to solve. You can't version an action API if you don't understand the states and transitions behind them. 

Of course, people like Stu or Mike will never admit such a thing publicly. They will always say, "but... if you look here ... there is a promising solution that that problem". Boloney guys. Pure and complete boloney. We have endured 3 years of that boloney. REST is not a programming model. It has never been and it will never be. Deal with it.

I have ordered Subbu's book (hopefully he will give me an autograph), so I'll wait until I get it to make my final comments on versioning, but so far I think (reluctantly) that Stu belongs to the REST wall of shame. It is time to get real and provide real recommendations. Recommendations that don't let people loose like the ones that have been made for so long and got us where we are today, i.e. nowhere.

I see no success in sight and no sign of possible success either. The (other) REST is a fraud, nothing less, nothing more. Innovation is not "serendipitous" innovation requires hard work and courage. Innovation doesn't happen in pretty power points and IEEE articles.

RESTfully yours,

JJ-