I’ve been thinking about your point recently, and through re-reading your article, I think the point of my RETRO model has not been communicated well enough (to you or anyone else for that matter). The reason I designed RETRO was as a thought experiment to show that a pattern for atomic transactions can be instantiated without violating the constraints of REST. As you know there has been much debate around this point. RETRO was not meant to be sold as a product, but to advance the debate. In fact, it is not even implementable as a module at all as it needs to be tightly integrated with the underlying API to begin with. So in the context of the thought experiment I described, I think examining whether it succeeds or fails in its ambitions is entirely appropriate.

Regards,
Alexandros

Cheers

BTW, getting sales, development, community, customers, and users all on the same page is a difficult task. Thats why its important to set down a vision and a direction first and why, IMO, something as trivial as a name helps to articulate this vision.

Now, I don’t read the part of marketing morons anywhere. Just in case, since I have that part of academy too, business admin, I can tell you marketing doesn’t sell with commercials indicating the nuts and bolts of something. They sell with benefits, with buzzwords and brand names. That is because each word contains a meaning all people in the target market understands. That is perfectly correct. If developers say you will deliver X, sales will sale X (with some greatness, granted). If you end up delivering Y, it is you the one to blame. If you deliver Y because community said it was X, then it is the community to blame. In all cases, academy is not the one to blame (well, in these cases they are not).

What is not correct is take your old technology, wrap it in the current buzzword because it behaves similar, and then sell it as the real thing using the name.

But, until a company actually ships a project or product that somebody can actually use, it is completely unprofessional to accuse them of changing the meaning of a buzzword to sell and repackage old technology. Even more unprofessional to call them “marketing morons”. This is especially true if the effort is open source where even the initial planning phases are done in the public before a single line of code is written.

What is not correct is take your old technology, wrap it in the current buzzword because it behaves similar, and then sell it as the real thing using the name.

Well said. I now see that the title of this post did lead to competing opinions. Bastardizing the terminology either due to ignorance or marketing needs is always a bad thing. It leads to permanent confusion and lost productivity. On the other hand, developers employing HTTP must understand what RESTfulness means, and try their best to use the principles and make judicious tradeoffs when it does not fit their environment.

One thing is the REST architecture style and another is the thing vendors are selling. Look at the sales pitch, unless they mention the architecture style constrains and why those are there (benefits), I feel they are selling buzzword meal. And one thing is what sales people sale, and another one what developers got.

So, selling the architecture style is fine if sold to architects. But taking the style, deriving from there development tricks and selling them as a package to developers is not selling the style, is selling a particular interpretation/implementation of that style.
There is were not academics, but industry practitioners that know about it, can evaluate the tool and say you are selling cat meat and not crab meat. See?

For instance, I can tell you that wrapped document style is not document style, but RPC style. Because I’m an academic (angry or not) that also codes, and evaluates tools, and I know when a tool is not delivering. And I can tell you that RPC in the wrapped document styles does not deliver the same performance as the real document style due to a full set of flaws in the implementation, server and user side.

What vendors should do is go talk to the angry academia and ask why the implementation will not deliver what REST promises, if you feel you are implementing what REST style promotes. If what academia tells you is missing is not what you are selling, then fine. If what academia tells you improves your tool, great!
What is not correct is take your old technology, wrap it in the current buzzword because it behaves similar, and then sell it as the real thing using the name. You have for instance a URI template engine, and you see REST has something to do with URIs, and then you create a tool to easy the RPC using URI templates and sell that as REST. See what I mean?
Do you know some perfumes that sell “our version of…”. That is what I mean.

Just think how silly it would be if you couldn’t describe or name your project/product with “object”, “aspect”, “object-oriented”, “service-oriented” because you had to make some trade-offs in your design or implementation? Imagine if REST were trademarked or standardized? There’s a whole set of well-known vocabulary that you wouldn’t be able to use to describe anything you were doing and you’d end up having to reinvent the whole shabang with your own words. Pointless and a complete waste of time.

Beyond that, marketing and selling products based on a style is done effectively throughout all industries. It conveys a direction and vision for your project/product line. Branding a product line based on a style conveys to a potential user how they will consume the offering. A name is the most efficient way of articulating to a potential user what you are trying to do.

In the end, my users don’t care what some angry academic says about me or my company. I’m just sick of spending all these engineering resources on a SOAP stack and all the crap tools you need just to have an ounce of productivity. If I have to use REST as a brand to steer my company and users away from WS-*, then, IMO, the end justifies the means. Spending time justifying my existence is a complete waste of time and energy.