

Protocols over APIs - julien
http://blog.superfeedr.com/protocols-over-api/

======
jiggy2011
The problem is that they don't want you "changing the openid2.provider href in
the HTML and I was done".

They want you to write your app so that all of your code is so hopelessly
coupled to their service and API that it may as well just be an extension of
it.

I had a similar revelation when I was writing an S3 backup system recently, I
was writing hundreds of lines of Java that was catching exceptions that I
hadn't even heard of while calling libraries in the namespace of a company
that is known for selling books. What on earth was I doing?

So I wrote a 3 line bash script to rsync to a bunch of places and added it to
crontab. Now that means I can change backup providers whenever I want with a
single code change.

As a separate point there is something to be said for stateful protocol
(especially open ones) instead of stateless by design API stuff like REST.

I am considering the use of an IRC server as a backend for a messaging/logging
system.

I like building systems that can be debugged with telnet.

~~~
ken
They don't want me switching away, but they should also recognize that
programmers like me are lazy/smart enough that I'm much more likely to switch
_to_ their service if I know I can easily switch away.

(But being lazy, I'm not going to switch away from them on a whim. Even if the
interface is the same, there's still a cost to the testing and such that would
be needed. I mostly want to know that there would be a reasonable migration
path.)

Joel Spolsky made this point about Excel once ("Strategy Letter III: Let Me Go
Back!"): its adoption really took off once people could _write_ 123 files.

~~~
jiggy2011
That's an interesting point but I think it works more in favor of small
providers trying to gain market share rather than incumbents.

Amazon's strategy with AWS seems to be to hype it so much that anybody who
isn't using it feels like they are some sort of neanderthal since everyone
talks about how everything is moving "to the cloud".

Interesting that he uses Excel as an example since I imagine (I haven't used
Excel for a while) that saving data in a modern version of Excel makes it
incompatible with anything else (at least it would do if OpenOffice didn't
reverse engineer the format).

~~~
ZoFreX
The format didn't need to be reversed, it's (almost) open. Additionally there
are plugins for the older versions of Office to let them work with the newer
format, and it's much much easier to write tools to do things with Word files
now - just crack one open and take a look (it's a .zip file full of XML
files).

------
iparamonau
It's not about the Protocols over APIs. It's not even about open-web over
walled-gardens.

Take a quick look back: Google Wave wasn't a safe bet, even though it was a
federated protocol. On the other hand Facebook's Open Graph is a safe bet,
even though it is hardly a protocol, but rather FB's API.

If you'd like to be sure something doesn't get deprecated, make sure it is
widely adapted before you use it. In this case you would be a part of
community, whose opinion has a leverage over technology providers.

But this way you may miss an early opportunity. It's all about choices.
Luckily, we have plenty.

------
officialchicken
I want to assume that if we had versioning built into more of our common
languages and runtimes (some do), than this would not be an issue.

Also, I hate to nitpick, but protocols usually describe stuff like how to
drink tea formally in a garden with a king or queen (workflow), not API's
(implementation). I think what they mean is URL naming scheme, but I could be
wrong.

------
StavrosK
What if the two services have different features, even slightly? The protocols
are instantly incompatible. The problem is that the feature set, and thus the
protocol, is strongly tied to the provider, and decoupling the two doesn't
make much sense.

~~~
julien
Well, I'd argue that the protocol hasn't been designed correctly. Don't forget
that every single website out there use HTTP as their main protocol, yet, they
have very different feature sets, capabilities and even goals!

~~~
phillmv
We're reinventing the wheel, yet again.

Wasn't this what CORBA, XML-RPC, or SOAP was meant to solve? And then we all
happily ditched them for loosely defined RESTy JSON because it was so goddamn
easier.

I think TFA is describing a legitimate complaint; but I don't think the RESTy
CRUD twitter exposes is all that difficult to abstract.

Amazon on the other hand…

~~~
theatrus2
Amazon's protocols were clearly designed by a Java EE developer. Not that
there isn't anything inherently wrong with them, and they are very flexible.
They're also somewhat stuck with them based around the huge amount of code
which interfaces with S3/AWS.

There are some problems with no _good_ solution, namely the signed parameters
in Amazon's case. How do you sign JSON? Is there a "canonical" JSON format
that will allow signing consistently, and verification? All the approaches
I've seen are incompatible in some way.

Client-side SSL is another solution, but its much less flexible (i.e., token-
generated requests wouldn't be easy)

~~~
userdeveloper
Stuck with Java. Exactly.

