BT
x Your opinion matters! Please fill in the InfoQ Survey about your reading habits!

Has Web Style Worked?

by Mark Little on Mar 24, 2013 |

In a recent posting, Jean-Jacques Dubray (JJ) reminds us that it is almost 7 years since Tim Bray predicated the end of SOA:

I did an interview and a podcast [...] and the question came up in both, and in the hallway talk too: “What do you think we should do about SOA?” Which weirdly, nobody had asked me before, and I could find only one answer: “Don’t do anything. ‘SOA’ may have meant something once but it’s just vendor bullshit now.”

Tim ended by stating (predicting) that rather than SOA being the future, Web Style was the future. As JJ mentions, that predicting opened the doors for many others to follow over the coming years, including the likes of Anne-Thomas Manes and others. One of the results was that many SOA projects were slowed or killed, with JJ having his own direct experience of the former:

My manager at the time told me that Tim Bray's post was circulating in our IT department and he didn't know where to start to craft an answer to his management. His team had built their own ESB at a time when hardly anyone had heard of XML and several years of hard work and constantly rising transaction volumes (a respectable 10 M requests/day at the time, in early 2007)  were now jeopardized by a single paragraph written by Tim Bray.

Well JJ has spent some considerable time over the years on InfoQ and elsewhere, talking about the problems that Web Style overlooks. In this recent article, he has also been taking a look at many of the services that purport to implement Web Style:

Out of 9000 APIs [in the Programmable Web's directory], my best estimate is that less than 1% are following Tim Bray's Web Style. They are all but following an "API" style, short of RPC.

And JJ gives some examples of what he means by this by considering what he believes is a representative sample:

  • Ask Ziggy which offers the ability (sic)  to define "actions" (such as Play, NextSong, Previous Song, Shuffle...)
  • WhatLanguage explains that you can use, as you wish, a GET (if your request is less than 7500 chars) or a POST to the same URI to detect the language of a given string
  • Do.com actually seem to be offering a Web Style API, but it does not do much, it is simply CRUDing 5 resources (tasks, project, users,...)
  • SkyBuffer is also following the Web Style, but just like DO.com, this is just some CRUD on a couple of entities
  • MaShape which is a "Cloud API hub" is very interesting because they offer a better way for developers to consumer APIs. How do they do that? They invite developers to "Learn how to describe your API on Mashape to autogenerate client libraries and documentation". Yes you heard right, after years of bashing, developers start talking about client library code generation.

 JJ thinks that the API approach is at odds with the pure Web Style that was being pushed by Tim et al:

Wasn't the Web Style all about the "Uniform Interface", Bookmarks and auto-magic HATEAOS? not to forget standard IANA types? Yes, you don't hear that kind of argument much these days. APIs rule. People are no longer ashamed to use a verb in their URLs or POST a (complex) query. Most importantly, MongoDB showed us that there is a lot more needed to CRUD than these 4 little verbs and an anemic URL syntax. Developers and Architects are so desperate to go around the "Web Style" that they even try to add namespaces to JSON.

When looking at these supposedly Web Style services, JJ comes to the conclusion that it has in fact failed to deliver on the hype and is in fact "dead". However, JJ goes even further than this, declaring the Web itself to be all but dead:

[...] between developers who can't figure out how to produce anything of value with HTML5 and compete with Native apps and end users finally getting cold at the wonderful idea of being "the product" central to the Web business model. Tim Berner-Lee which is coming out every six month with a "Long live the Web" message but after a wrath of security abuses, it seems that even a KBE can no longer save the Web.

Fortunately the article doesn't just leave us with a gloomy overview of the past and the "technical debt" that has wraught. JJ looks at where we are today and the influence of new waves such as mobile, which he believes represents possibly the biggest paradigm shift computing has ever seen:

Few people would remember, but software engineering was built on an old, very old paradigm of "file processing" which culminated with UFS. The desktop metaphor and the main usage patterns of PCs remained anchored in "file processing". Mobile is no longer about files, mobile terminals assist us in pretty much any activity we do. If nothing else, future operating systems will be activity centric.

However, he believes that we must also leave Web technologies behind in order to succeed:

The best user experience will win, anyone who has, is or will be betting against it will lose. The Web rose, because it too, once, provided a better user experience. It didn't rise because it was "the Web".

And finally, JJ states that we have to be far more pragmatic about how we approach problems and really learn from the past:

More CRUD is not going to cut it, even with an API as superbly designed as the MongoDB API. We also have to grow up an understand that, OO is the wrong paradigm to represent interactions between distributed components. Hence we have to stop reifying everything we do into stateless singleton method calls. Annotations on a class are simply too weak to drive the semantic revolution that SOA started and we now need to finish.

But even taking on board all of these changes that JJ suggests, what is the ultimate goal? Well JJ thinks it is a robust Composite Programming Model where the model and view are free from one another but still properly connected, following an activity/action/lifecycle paradigm. Unfortunately JJ doesn't go into a lot of detail in this article on that model, but perhaps the intent is to follow up with some related publications.

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

The problem ... by Mark N

SOA != to Web Services. In fact, it is != to the Web. SOA is about "loose coupling" and "business services". It is an architecture, not an implementation. If you completely use only Web Services to implement your SOA ... it probably is not loosely coupled (or at least not enough).

So back to what you are saying ... What are you comparing? WS to REST? If so, while REST has some advantages it suffers from too loose of coupling. You have to code from documentation vs "API" (the same issue that most scripting type languages have). So, while you might have initial "productivity" and "speed gains", your overall maintenance will suffer and thus, quite possibly, your TCO.

www.infoq.com/news/2007/07/soa-ws-relation

Re: The problem ... by Jean-Jacques Dubray

Mark,

the question is: "Did the web style allow us to build anything of value?", the answer is no. This is not about REST vs XYZ, of the old SOA bla bla bla. The fact and the matter is that there are now 9000 public "APIs" registered in a "manually maintained" registry, which does not offer itself an API ...

I content that:
a) not only the Web style never enabled anyone to build anything of value, value was achieved when people were producing APIs (which all can be well described by a good old WSDL)
b) it set us back 15 years, and eliminated the very bit of progress that we had established with technology neutral contracts

Hence, now people build their client code by hand or service provider have to deliver client libraries

I don't think anyone can dispute that.

JJ-

Re: The problem ... by marc prades

So should we all get back to soap ? why so much apis use RESTinterfaces is more because of javascript and json than actually being restfull. Soap doesnt really work with web clients.

Re: The problem ... by Mark N

So what is the "API" style? I tried to Google a good definition, but came up empty. I saw plenty of people talking about it.

To me, WS and REST are APIs, just to varying degrees and Pros/Cons. There are other ways to expose APIs.

Re: The problem ... by Jean-Jacques Dubray

The good old action oriented synchronous client/server "call" wired to a method or a function. It's not because you change the encoding from SOAP to HTTP that you changed the semantics of the "call".

Utility is the key by Hermann Schmidt

Web Style was a reaction on WS* frustration. WS* could have survived the web world if:

- The cemented dependency on XML and XML Schema had been removed. XML Schema is a failure. It has too many superfluous constructs and fails to address versioning and back/fwd.-compatibility miserably. XML with its origin from markup language fails to address in a simple way the fundamental datastructures of any transport data format: Arrays/Lists, Maps, Composites. Too many names and patterns need to be invented for trivial structures. Simplicity was demanded and satisfied with JSON. Versioning is still a tough problem but at least not as terrible as before.

- The browser vendors had any interest in natively supporting XML as much as JSON. With XML being alien to the native language JavaScript, this is no surprise. A format that doesn't integrate with the browser platform well these days is doomed.

- The HTTP protocol would have been properly supported once the bold vision of transport transparency showed signs of fatigue. Did anyone use anything else than HTTP? Technology neutral maybe, but nobody needed that.

- Unnecessary ballast from the WSDL (bindings, message parts, ports) had been dumped. WSDL 2 attempted to fix silly names (Ports - wtf?), but it was too late already.

- The "loose coupling" propaganda had not been an outright lie.

A technology with useful parts gets dumped nevertheless if it is stubbornly refusing to adapt and doesn't fix its annoyances. The current Web Style (not identical to REST) counter swing strips abstraction and also convenience, and starts all over again from a lower level (that's your 15 years backlash), and then incrementally tries to build on top of that.

Nobody wanted to build on WS* incrementally. That is the actual tragedy. It all began from scratch.

I am not saying that the current "Restful" world has solved all old problems in a better way - if at all. There are reinventions (JSON Schema, WADL for example), which repeat concepts from WS* with ballast removed. That is a good thing.

Unless there is no public killer API, which performs services, which had never been possible without hypermedia and media types, and which becomes a light post, I don't expect the 80% crowd to absorb the full REST architecture. The RPC-style has not yet vanished from the minds of the developers.

Is there a new universal programming model for everyone? I don't think so. People just go as far as they feel is necessary, on arbitrary abstraction layers. A few outstanding minds produce innovation and the crowd might follow if they see value. It is not driven by a common sense of THE MODEL, I think, rather by the utility of the available products whose style gets copied or adapted.
I think the reason that full REST has still not arrived after quite some years is the missing easily accessible proof of utility without lengthy explanations.

Re: Utility is the key by Faisal Waris

Agree mostly.

I don't believe the REST model where the client knows how to generically handle all resource representations, is practical.

So this leaves us with contracts of one form or another.

In hindsight, all of the time/energy wasted in soap-vs-rest discussions could have been better utilized by evolving a better way of describing contracts.

As as example, oData (odata.org) is a decent model for some usecases. However note that the full specification is quite large (approx. 500 pages for the specs listed on the site) and parallels in complexity to XML Schema / WSDL. OWL and related specifications are probably at the same level of complexity. There is no free lunch...

Re: Utility is the key by Jean-Jacques Dubray

+++1

Re: Utility is the key by Rickard Öberg

"I don't believe the REST model where the client knows how to generically handle all resource representations, is practical."

I know of one, it's called a "web browser". Try it out, it's amazing how it can generically handle resource representations. Very practical, too.

Re: Utility is the key by Mark N

He didn't say he didn't know of a client. He said he doesn't believe where one "needs to know how ... is practical". So the question is: what does he and you consider practical? To me, having to code by constantly looking at documentation (i.e. the same as one has to do with JavaScript APIs) is not "practical". That being said, it does have its advantages and is sometimes the right thing to do and thus might be situationally practical.

Re: Utility is the key by Alexandre Saudate

One more RESTafarian.


What actually happens is: browsers don't really know how to handle data, they only know how to handle presentation styles (HTML / XML / XHTML + CSS/Javascript). But the browser is not as smart as we all would like it to be; it rather needs human interaction so it knows what to do. Unfortunately, real-world web services go way beyond that, in the sense that interactions between several kinds of web services need to be done in order to achieve the completion of certain tasks. And, of course, these interactions are not to be made interacting with people (of course, no one would like to be interacting, all the time, with some service composition and get inputing data so it goes to CRM, and then, ERP, and then legacy...).

So, "the browser" doesn't fit this kind of challenge. It is naive to use this kind of example and to believe apps should handle data like browsers - where these last ones don't really handle data.

Re: Utility is the key by Rickard Öberg

Alexandre, but the point is that a browser can generically handle representations, and then provide an API for someone to use those representations (follow links, submit forms). Whether the link-follower or form-submitter is human or not is beside the point. REST apps, if automated, should be written with the equivalent of a browser as the interaction point to the REST service. The problem is that everyone right now is doing the low level crap themselves, and mixing up what should be in the app and what should be handling the generic REST stuff (like figure out whether to use POST or PUT on a form, which the form will tell through representation; no need whatsoever to put that into any docs).

Basically, the vast 99% majority of s0-called "REST" apps aren't, and so to say "hey that REST shit doesn't work" is kind of disingenious, because what is really being judged is "JSON over HTTP", which, granted, is stupid as hell for most apps.

So if you calling me "RESTafarian" means "hey here's a fucker that actually read what Roy wrote, dude, that's a crap load of words man", I say "guilty as charged". The more I apply REST on client and server, the simpler I have found both ends to become. But hey, don't take my word for it, try it out. Ya might like it.

Oh, and I found the "interactions between several kinds of web services need to be done in order to achieve the completion of certain tasks" to be just ridiculously funny, because that is exactly what REST is good at. Hilarious.

Re: Utility is the key by Alexandre Saudate

So you're suggesting that we should be building "browsers" everytime we need to interact with REST services ?

Also, the piece where I say "interactions between several kinds of web services need to be done in order to achieve the completion of certain tasks" I mean - automatically. Just as far as I've seen, REST causes us a lot of trouble so we can model, build and maintain this kind of AUTOMATIC interaction. But I'd love to hear some of your experiences. Tell us, did you successfully build an interaction between several REST services (and, when I say succesfull, I really don't mean "it worked", but - It was Roy's dissertation compatible, it didn't cause people nightmares when having to maintain it, and so on)?

Re: Utility is the key by Jean-Jacques Dubray

Perhaps we could start hiring humans to attend hypermedia payloads and make sure that the "client" calls link "dynamically".

Re: Utility is the key by Marko Milicevic

>> I mean - automatically

Alexandre, are you suggesting that the SOAP protocol somehow has a magical way of choreographing tasks "automatically"?

Could you please give real-world examples.

Thanks.

Re: Utility is the key by Alexandre Saudate

Marko, automatically means not being dependent on human beings to do so. SOAP has some intrinsic stuff that definitely help doing so:

- XML Schemas
- It's always bound to POST (it doesn't have to struggle against the other methods)
- It's kinda RPC, anyway

By having these kind of stuff by hand, SOAP developers don't have to struggle against modelling. It surely complicates a lot when it comes to several other stuff, like performance and easiness of use. But by not having the restrictions of REST, it helps a lot developing compositions.

It's not a coincidence that WS-* has BPEL and REST doesn't have, so far, any kind of mainstream orchestration engine (Dr. Cesare Pautasso is working on JOpera, but it's fairly away from being mainstream).


What is definitely a problem when it comes to REST services is modelling against such compositions. Once I came accross a scenario: picture out some search you have to carry against a database (easily, a case for GET). Now picture that this same case has to be logged, and the logging engine is in a different system (clearly a case for POST or PUT). Now imagine the following: this search is logged because it is billed. The client has to receive both the bill for the search and the search results. If he doesn't get the bill, the company that offers the service cannot assume that he is billed (and, therefore, cannot sue him if he doesn't pay - the same for any other legal actions). But, if the client receives only the bill, he can sue the company for being billed without search results.

In SOAP, such a modelling is a piece of cake. But REST has these restrictions, and we should relax these restrictions in order to achieve the desired result. (Obviously, we could not allow the client to coordinate the services in this case).

Re: Utility is the key by Alexandre Saudate

I thought about pigeon clusters at Google =)

Re: Utility is the key by Alexandre Saudate

Also (it was getting out of my mind, forgive me), what was in the table was about the contract. Some people believe that REST doesnt't need contracts because the browser doesn't have contracts and it's happy this way.

But most people that claims so forget about two important things:

1) The browser actually has a contract. It's the DTD for HTML.
2) The browser doesn't actually handle data, only presentation stuff. So it does not have to worry about having to do coordinate stuff because there will always be a human being interacting with these presentations. The same is not true for enterprise compositions.

Re: Utility is the key by Marko Milicevic

Alexandre. I would highly recommend you check out some good REST/Hypermedia education. Here are a couple of good books.
www.amazon.com/REST-Practice-Hypermedia-Systems...
www.amazon.com/Building-Hypermedia-APIs-HTML5-N...

They will answer many of the questions you have.

There is no reason REST can not do everything SOAP can. Any time you do a SOAP call, you could just as easily do a REST call (pragmatically). In my opinion REST has advantages over SOAP in being more simple to work with, more language neutral, more loosely coupled, and can evolve more gracefully.

I'm not quite following your example? The search needs to be logged. If you control the search, then have the search service do the logging. If you don't control the search, or do not want to add the responsibility to the search service, then have a proxy service handle the search which coordinates the search and logging services. I'm not sure where REST has problems with this?

>> automatically means not being dependent on human beings to do so

REST is not dependent on a human. Any program can make a REST call.

>> But REST has these restrictions

What restrictions would those be?

>> Some people believe that REST doesnt't need contracts

REST does have contracts. The HTTP mime-type (media type) is the name of the contract. Browsers handle a particular REST contract called "text/html". The contract is documented here...
www.iana.org/assignments/media-types/text/html

The spec is much more comprehensive than any XSD could be.

REST encourages more generic media-types and composition, but there is nothing wrong with creating domain/application specific media-types (contracts)...
stackoverflow.com/questions/14685672/how-to-cre...

The browser keeps getting discussed, which is great since browsers are an awesome demonstration of a REST client. But no one is suggesting that browsers are some universal REST client. They are html RESTful clients (mainly meant for humans) that handle the html family of media types (but not every media type).

>> 1) The browser actually has a contract. It's the DTD for HTML.

Actually the browser is able to interpret the html media type and all the other media types that can be embedded/referenced from html (css, js, images, etc...). Everyone of those media types has a standards doc. The html media type standards doc does include a DTD.

So yes, REST does have contracts.

>> 2) The browser doesn't actually handle data, only presentation stuff. So it does not have to worry about having to do coordinate stuff because there will always be a human being interacting with these presentations. The same is not true for enterprise compositions.

The browser doesn't handle data? What do you call all the bits that encode the html, css, js, images, etc...? I would call that data, and the browser uses the media-type contracts to understand how to interpret the bits. The html media-type gives a semantic spec of the data, but it does not dictate a visual representation. Browsers are an interactive/visual application of HTML designed primarily for humans.

But an application could be designed to use an HttpClient and (eg.) programatically browse amazon, search for a book, add it to a cart, then checkout. I could also spider the web programmatically, scrape semantic data, automatically analyze it and index it. You could also acceptance test your web app with Selenium (an http client) by automatically surfing your usecases. You could also use an HttpClient to interact with other standard media-types like json, xml, images, atom, etc...

Re: Utility is the key by Alexandre Saudate

Marko, to this point I find this conversation completely useless. I'm not quite sure you got all of my points (perhaps my English is failing me?), and I'm not willing to explain it all again.

All I would like to assure you is that I'm no student in both REST and WS-*. I'm perfectly aware of both styles pros and cons. As I tried to explain earlier, I was just trying to show some case where, no, REST is not as good as WS-*.

People over the world are starting to see it, now. Everyone knows SOAP/WS-* is no silver bullet, but not everybody knows that the same applies to REST. When the time comes, I have no doubts that we will end up following some style that has both styles pros, and the whole discussion will move towards... something else :)

Silver bullet? by Tero Vaananen

Companies, developers, API builders - who ever they are - are clearly voting with their own submissions out there. Hardly any of it is pure REST, hardly any of it is SOAP. When it is about integrating with someone's API, you do it with their terms. You may have little control what they do and how they choose to expose their services. Do what you want in your own domain, if you can, but even there idealistic views often fail. Unfortunately, you deal with people, and people do what they wish. Not many are REST gurus, not many want to deal with SOAP; they just want a straight line solution and spend the minimum effort doing so.

Often that is just "web style". Many would argue it is short sighted, and it may be, but it is often easy for those who have a mental model of an API in their head. "If you come to my house, it is my rules." I have not generally seen a SOAP API that you did not have to "learn", and in general they are just as messed up and twisted as any "web style API". But, given the choice, I still prefer the web style mess over SOAP mess any day. It may depend on your context, but the environment I figure most people deal with and know is the "web stuff", and if anything, that is the proverbial nail in the SOAP coffin.

Hypermedia by Jean-Jacques Dubray

Not sure David Heinemeier Hansson could have any a priori about REST and hypermedia in particular. Yet, he wrote that. All the comments are definitely worth a read. It seems that some people would never learn, no matter how much evidence can be mounted against their rationale.

That being said, I am glad to see that much fewer people are drinking the cool-aid than seven years ago. In reality, we have made no progress at all on the distributed computing front in these seven long years. That's the really sad part about this whole story.

Re: Silver bullet? by Jean-Jacques Dubray

Tero,

nobody has ever argued that SOAP would have magic powers and developers could start using operations and schemas without reading the documentation. A long time ago, in the dotcom era, a handful of people have talked about going from discovery to service consumption without any kind of hand coding, but these people were at best naive. Nobody really believed them, even though the W3C ended up putting it on some kind of architecture document.

That being said, writing the client code to consume a Web Service was forever eliminated, things like authorization or even versioning had a sense because you could refer to a well defined perimeter. Most Web APIs could potentially be describe by a WSDL, there is nothing in the Web API style that is innovative or contrary to what was defined in WS-*. I like JSON better other than for the fact it does not have a schema. I don't care about SOAP or not SOAP. This is just encoding of the exact same semantics.

The fact and the matter is that if you carefully look at JAX-RS and JAX-WS client and server code, they look exactly the same, like for line. So what have we gained? what have we lost? our time for sure...

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

23 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT