SOA vs API?

[Sachin Surana]

Hi,

I happened to look at the slide and also related video but unfortunately still do not have  a crystal clear view. http://www.slideshare.net/apigee/apis-inside-enterprise-soa-displacement

Is my understanding correct?

1. SOA and API are complementary paradigms/technologies. APIs are a facade to SOA to expose them to the outside world?

2. SOA was aimed to provide an integration mechanism/guidelines for enterprise while APIs are generally aimed to make the backend systems public? Also, APIs can be internal to the organization.

Regards,

Sachin

[Kin Lane]

Your understanding is in the ballpark.  APIs were one tool in the SOA toolbox. Except you are seeing APIs as just technology.

APIs have jumped out of the enterprise toolbox, and found success in the richer oxygen environment of the Internet, escaping from the claustrophobic environment of the restrictive enterprise network in which strict governance was imposed, and technologists decided everything.

After going outside the firewall, APIs became about the simplicity of REST + JSON over HTTP, putting these resources closer to actual problem owners--flipping the governance of SOA on its head, making APIs more about partnering, collaboration, transparency and openness, and not just about control. After escaping the governance and the bottleneck of traditional IT, this new breed of APIs allowed for new types of innovation, business models and opportunities amongst not just open developers, but actual business owners. A new world emerged that the governance overlords of SOA could never achieve or even see.

Allowing the humans to win over the machines!  Making for a new formula for success that can be applied in public, partner or internal environments.

Kin Lane

API Evangelist &

Presidential Innovation Fellow

kin...@gmail.com

apievangelist.com / apivoice.com

--
You received this message because you are subscribed to the Google Groups "API Craft" group.
To unsubscribe from this group and stop receiving emails from it, send an email to api-craft+...@googlegroups.com.
Visit this group at http://groups.google.com/group/api-craft.
For more options, visit https://groups.google.com/groups/opt_out.

[Sachin Surana]

Thanks Ken. Thanks for confirming.

1. APIs were one tool in the SOA toolbox = That really clears clutter out my head.

Further questions

1. What is difference between a service and API? Is it OK to say that APIs are "loose" services?

2. Can internal SOA integration be based on APIs instead of services?

[Felipe Sere]

Services provide APIs, or in other words, you interact with services using their APIs.

APIs are not a separate artifact deployed next to your service. 

The difference between "SOA" and "Web APIs" is manly in their purpose. A SOA is a way to organize systems within a company and maximize reuse and efficiency. You only have one "customer-service" or "shipping-service" or "car-booking-service" which is used by multiple other services or products from you company. 

A Web API is a service you expose to customers over the Internet so they get some value and you make money :)

Whether there is a SOA behind the Web API or an enormous monolith service does not matter for the customers. 

--
Gruß,
Felipe

[MattM]

I think this topic is always interesting as you can see the different perspectives and definitions.  Just as SOAP wasn't really the point of SOA, REST isn't really the point of the whole API movement.  If you design a service-oriented infrastructure that allows your business components to function as a platform for development, you will be well-prepared to succeed in the API ecosystem.  But--as Kin points out in his post--the emphasis on the human element that is so popular with the API ecosystem stands in stark contrast to the dictatorial approach popularized with SOA Governance.

Thanks, m@

To unsubscribe from this group and stop receiving emails from it, send an email to api-craft+unsubscribe@googlegroups.com.

Visit this group at http://groups.google.com/group/api-craft.
For more options, visit https://groups.google.com/groups/opt_out.

--
Gruß,
Felipe

[Toralf Richter]

Hi,
I like the statement that "APis have been  out of the box of inertia imposed by SOA governance2 ... nice one.

What I like to add to this discussion, is something that I increasingly notice in the API discussion, where API is set equsal to (REST) web service. For everyone with a background in software development this is aiming a bit too short, I'll try to explain why ...

Before there was even SOA there was (and still is) a paradigm describing modular software architecture, which basically said you compose software into different dfunctional sub components, and these ideally interact through defined and stable interfaces (=APIs of the components).

The the modular concept was extended beyond components running in the same runtime / server but on different machines, and maybe different data centres. Which took us to SOA in the enterprise context. API interface stability in the applications that take part in large SOA constructs became important topics, as you are rarely ever able to deploy all compinents at once, to propagate a breaking change. So this is where loose coupling in APIs really started to become interesting. The trend from more or less runtime environment specific service binding and service coupling technologies (let's say RMI or JMS, specific RPC mechnisms) went more towards cross-platform compatibility (which is evry much web services / HTTP APIs)

From there, web services for internal and external purposes started to become more and more quickly. With Web 2.0 and in my view even more the whole smartphone / tablet revolution web service APi became the driver, data provider, backend for those leightweigh application that most run on the client but still need to access a variety of backend system ofcourse. In conseqeunce of this, and because the means of choice was often an HTTP / REST / JSON web service API, the word API has aslo seen a shift of meaning making very much synonymous with HTTP web service or even with REST for many.

But, the good old Advanced Programmable Interface has been around longer (and will be around for bit more I guess).

Cheers, Toralf

[Herman Peeren]

just a small correction: API = Application Programming Interface, not Advanced Programmable Interface.

[Toralf Richter]

Hmm,
see below from Wikipedia :-)

"API, originally Advanced Programming Interface but now more commonly known by its near-synonym, Application programming interface, is any defined inter-program interface."

(http://en.wikipedia.org/wiki/API_%28disambiguation%29)

[Herman Peeren]

Thanks. Had never before seen that definition (although into programming since 1977). But I think "Application Programming Interface" better explains what is does, for that interface is neither necessarily advanced nor programmable. It is an interface to program an application.

[Richard Mateosian]

Oh! I always thought it was Arcturan Plan for Invasion. I wondered why so many of you were in favor of it.   :-)   ...RM

On Mon, Aug 19, 2013 at 1:18 AM, Herman Peeren <herman...@gmail.com> wrote:

API = Application Programming Interface, not Advanced Programmable Interface.

--

Richard Mateosian <x...@pacbell.net>
Berkeley, California