Slashdot Mirror
OAuth 2.0 Standard Editor Quits, Takes Name Off Spec
New submitter tramp writes
"The Register reports, 'Eran Hammer, who helped create the OAuth 1.0 spec, has been editing the evolving 2.0 spec for the last three years. He resigned from his role in June but only went public with his reasons in a blog post on Thursday. "At the end, I reached the conclusion that OAuth 2.0 is a bad protocol," Hammer writes. "WS-* bad. It is bad enough that I no longer want to be associated with it."' At the end of his post, he says, 'I think the OAuth brand is in decline. This framework will live for a while, and given the lack of alternatives, it will gain widespread adoption. But we are also likely to see major security failures in the next couple of years and the slow but steady devaluation of the brand. It will be another hated protocol you are stuck with.'"
To be fair, it's a hard problem. Let's take the analogous example of a word processor. Surely, we can come up with something less bloated that Microsoft Word? Let's just get rid of all the arcane features that only 1 percent of the user base wants. That sounds good, until you find that entire industries (such as legal) run their business on Word and depend on those arcane features. Another user base (such as sci pubs) might need an entirely different subset of arcane features. Then there are those globalization features needed to support those who don't speak or write English as their primary language. So what are your options?
- only support the common subset that everyone wants. This would work at some level, but it's no longer a commercial product. This would perhaps be the mindset of a Open Source developer.
- support more specialized features via plug-ins or add-on packs. This is a maintenance, deployment and security nightmare, as we've seen with web browsers.
- support everything, which is what Microsoft does. It's a very unwieldy package.
REST is better than soap because it uses the features of the transport instead of ignoring and duplicating them in an opaque fashion. SOAP is like having every function in your program take a single argument consisting of a mapping of arguments. Or a relational database schema with only three tables: objects, attributes, and values. In other words, SOAP is an implementation of the Inner Platform antipattern.
As a regretful author of several WS-* specs, after I got sucked into the vortex of IBM and MS when they passed too close to our academic lab, I felt exactly as Eran Hammer stated in his blog. He wrote, "There wasn’t a single problem or incident I can point to in order to explain such an extreme move. This is a case of death by a thousand cuts, ... It is bad enough that I no longer want to be associated with it. It is the biggest professional disappointment of my career." I have used so many of those same phrases in reflecting on my experience with other veterans of that period!
And I'll tell you, XML and SOAP have no semantics either. They simply have a baroque shell game where well intentioned people confuse themselves with elaborate syntax. XML types and type derivation are syntactic shorthands for what amounts to regular expressions embedded in a recursive punctuation tree. There is absolutely no more meaning there than when someone does duck typing on a JSON object tree, particularly after the WS-* style "open extensibility" trick is added everywhere, allowing any combination of additional attributes or child elements to be composed into the trees via deployment-time and/or run-time decisions.
As a result, I am rather enjoying the current acceptance of REST and dynamically typed/duck typed development models. It is much more honest about the late-binding, wild west nature of the semantics involved in our everyday web services.
Ignore all concerns but scalability, and REST becomes far more preferrable than SOAP.
You don't have to ignore any concerns. SOAP was always a bad idea, as there is nothing to be gained from it you cannot work out by the combination of the HTTP protocol with REST style access.
This was obvious even in the very earliest days of SOAP, when people at that time where noting that REST was so much more practical. I had to use it off and on with various internal IT projects but it was always a bad deal, and just about always was eventually moved to a REST style service so people could get work done.
That said, there's one aspect of SOAP that popular REST specs are missing: a definition language.
As you note, it's called JSON, and we've been using it for years. It doesn't "need to be in the spec" when everyone is doing it that way.
But even then, having a documented result schema would be a huge improvement
No, it's really not useful. It's overhead. It takes more effort to maintain such a formal interface than to have people simply consume JSON as they will. And often the parts of the system that are supposed to process those formal definitions fail. All around just a horrible block to getting things working the way you like.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
I bet he died from a heart attack while plowing his twink boytoy.