
How APIs Fulfill the Original Promise of Service-Oriented Architecture - hestefisk
http://www.infoq.com/articles/apis-soa
======
bcg1
The main problem with "SOA" is that the big software corporations (the type
that often have 3 letters in their names) realized they could make millions by
layering on new 1000 page "standards" on top of the old 1000 page standards
and selling crap solutions to CIOs via golf course handshakes.

Now they've got their eye on "APIs", so watch out. And by the way if the
author is right about the trends in "enterprise" (and I believe he has a good
handle on it) the whole "schemaless" fad is going to get real ugly, real
quick.

~~~
skylan_q
Sticking to the theme about gripes about APIs, why do so many companies have
APIs and no webhooks? Polling sucks. Many SaaS providers will say it's "hard"
to implement webhooks but they have an API available. I'd like to know what's
so hard about making webhooks available.

I've developed a system that's supported webhooks and it was actually easier
to create webhooks (and have users submit endpoints on specific events) than
it was to create a proper public API for the same service.

~~~
lkrubner
"deliver exactly once" is still an unsolved problem in computer science, so
any webhook service is left with the options:

1.) only attempt once

2.) attempt x number of times

3.) attempt until delivery is confirmed

All of these can be done, but there are nuances and complications. It's not
trivial, which is why we don't see more of it.

Also, and perhaps most obvious, if they force you to poll, they are putting
the burden of development on you, whereas if they offer webhooks, they have to
take on the cost of development themselves.

~~~
jonahx
The difficulty of a foolproof solution isn't a great argument against a
solution. That is, many cases, I'd rather have a webhook with the "only
attempt once" strategy than an API I have to poll. "Pretty reliable" is often
good enough. I think OP's question is valid.

~~~
jjp
Whether pretty reliable is good enough depends very much on what you are
trying to achieve. I'd rather my salary wasn't deposited into my bank account
on a pretty reliable basis.

~~~
paulddraper
I'd be okay with "at least once" :)

------
aryehof
My belief is that how to divide systems into small pieces and have them
communicate technically, be reused and composed, is masking the real problem.

The real problem is representing and implementing a complex business problem
or system _within_ the service or application.

Technical emphasis instead of one on the business solution - of modeling the
problem domain into code - is a bad smell?

~~~
collyw
But it will scale on AWS....

------
rdli
The problem with the premise that APIs fulfill the promise of SOA is that APIs
are necessary but not sufficient to describe the interaction between two
services. For example, protocol semantics such as retry in case of network
failure is absolutely critical to the definition of the contract. The Slack
developer "API" is a good example -- not only do they specify your standard
REST/websockets APIs, but they include semantics such as rate limiting.

------
Dowwie
s/API/microservices/

