APIs vs Services: Key Differences
Key Points
- Alan Glickenhouse explains that “business APIs” are self‑service, marketable web interfaces that expose a business asset to app developers, distinct from the older, purely technical APIs of the past.
- In contrast, a service (as defined in SOA) is a reusable implementation of a repeatable business task (e.g., credit check, account opening) that focuses on connectivity and internal reuse.
- The confusion between APIs and services arises because both can use SOAP or REST and both perform integration, yet APIs are packaged for external consumption while services were primarily built for internal orchestration.
- The shift from traditional SOA to modern API strategies moves the emphasis from a single, internal view of entities to exposing those entities as consumable, business‑driven APIs that can be marketed to developers.
- Microservices are introduced as a newer architectural style that further abstracts functionality into small, independently deployable units, but still aligns with the API‑first perspective of exposing business capabilities.
Sections
- API vs Service: Key Differences - Alan Glickenhouse explains IBM's definition of business/web APIs as self‑service, consumable assets, contrasting them with traditional services and microservices to clarify their distinct roles.
- API Strategy: Security, Governance, Scale - The speaker explains how encapsulating services for APIs reduces change costs while demanding high availability, robust security, and strict governance via an enterprise service bus, shifting focus from internal pilots to broad external consumption.
- Differentiating APIs from Services - The speaker contrasts APIs with SOA services—emphasizing that APIs aim for quick, secure, consumable calls with minimal integration, whereas services focus on extensive connectivity, governance, and reuse—and advises defining the intended audience when designing an API.
- Microservices, APIs, and Flexible Integration - The speaker explains how building microservices with an API layer enables faster market delivery, flexible internal and partner access, and maintains control and security over systems of record.
Full Transcript
# APIs vs Services: Key Differences **Source:** [https://www.youtube.com/watch?v=qGFRbOq4fmQ](https://www.youtube.com/watch?v=qGFRbOq4fmQ) **Duration:** 00:12:15 ## Summary - Alan Glickenhouse explains that “business APIs” are self‑service, marketable web interfaces that expose a business asset to app developers, distinct from the older, purely technical APIs of the past. - In contrast, a service (as defined in SOA) is a reusable implementation of a repeatable business task (e.g., credit check, account opening) that focuses on connectivity and internal reuse. - The confusion between APIs and services arises because both can use SOAP or REST and both perform integration, yet APIs are packaged for external consumption while services were primarily built for internal orchestration. - The shift from traditional SOA to modern API strategies moves the emphasis from a single, internal view of entities to exposing those entities as consumable, business‑driven APIs that can be marketed to developers. - Microservices are introduced as a newer architectural style that further abstracts functionality into small, independently deployable units, but still aligns with the API‑first perspective of exposing business capabilities. ## Sections - [00:00:00](https://www.youtube.com/watch?v=qGFRbOq4fmQ&t=0s) **API vs Service: Key Differences** - Alan Glickenhouse explains IBM's definition of business/web APIs as self‑service, consumable assets, contrasting them with traditional services and microservices to clarify their distinct roles. - [00:03:12](https://www.youtube.com/watch?v=qGFRbOq4fmQ&t=192s) **API Strategy: Security, Governance, Scale** - The speaker explains how encapsulating services for APIs reduces change costs while demanding high availability, robust security, and strict governance via an enterprise service bus, shifting focus from internal pilots to broad external consumption. - [00:06:36](https://www.youtube.com/watch?v=qGFRbOq4fmQ&t=396s) **Differentiating APIs from Services** - The speaker contrasts APIs with SOA services—emphasizing that APIs aim for quick, secure, consumable calls with minimal integration, whereas services focus on extensive connectivity, governance, and reuse—and advises defining the intended audience when designing an API. - [00:10:32](https://www.youtube.com/watch?v=qGFRbOq4fmQ&t=632s) **Microservices, APIs, and Flexible Integration** - The speaker explains how building microservices with an API layer enables faster market delivery, flexible internal and partner access, and maintains control and security over systems of record. ## Full Transcript
Hi, my name is Alan Glickenhouse. I'm
the IBM API business strategist.
Probably the question I'm asked more
than any other one is what's the
difference between APIs and services. Uh
this is especially asked by those people
who have spent the last 10 or 15 years
working on serviceoriented architecture
and services. Uh so I thought we'd
record a video and and just uh finally
answer this question once and for all.
And I threw in microservices as well
which is a new topic that's come up that
we uh get asked a lot uh about the
positioning as well.
So first of all from an API perspective.
So this is our definition chart for APIs
we talk about uh APIs application
programming interfaces and uh really the
term we should be using is business APIs
or web APIs. We're distinguishing a
business API from the traditional old
technical API that has been around for
decades. Uh these are business assets
that we want to make available in a
self-service manner uh for a particular
audience. And so we want to package
these assets up as a consumable entity
that we call a business API and market
this to an audience which is a a an app
developer that's going to consume this
API and use it. So business API is is
the context of what we're talking about
with APIs. My previous role at IBM, I
was on the uh serviceoriented
architecture team for IBM and I use this
chart a lot and so we talked about a
service as being a repeatable business
task. uh something like check customer
credit, open a new account. And so that
sounds a lot like what I just said an
API was. Uh and and so there's a little
bit of uh obvious reason why there might
be some confusion. In fact, it gets
worse. Uh if you look at uh what we were
doing with S SOA and services, uh we
mostly were using SOAP. Uh but you in
the more modern times have started to
use REST there as well. In APIs, we most
often use REST, but we could also use
SOAP. Uh the purpose for an API I said
was to expose a business asset as an API
and for a service we said to was
encapsulate a repeatable business task
as a service which sounds very similar.
And do they both do integration tasks?
Yes, they do. So so this is what's
causing the confusion. And it's pretty
easy to see why that someone who's very
familiar with S SOA and services might
be confused by APIs. Uh and isn't this
something that they've already done? And
and maybe this is just a new name for
the same thing. In fact, what we've done
is just look at what they have in
common. Let's take a look at maybe some
of the things that are different, right?
So, in the S SOA world, the focus was on
connectivity and reuse. We were building
these services to drive reuse of these
services. So, we had a single view of an
entity, a single view of a customer, a
single view of an account, a single view
of an order. And anyone who wanted the
information about that particular asset
would come and reuse that. And then we
focused a lot on the connectivity of uh
the different services in that uh in
that environment typically inside the
enterprise dealing with the systems of
record. The sharing was about
effectiveness and cost. We're going to
reduce the cost of future projects that
we did in the enterprise and most of the
audience uh that we were targeting the
services for were internal. If we did
make the services available to a few
partners, it was difficult to do that.
we had to set up the security and do
some training for them to consume this
uh this particular service and so it was
not something we could do for the masses
and the encapsulation aspect was about
less to change we were going to change
what maybe was behind that service
interface uh and we wouldn't have to
change all the consumers of that which
is again back to the cost issue the
focus for APIs is about consumption and
speed to deliver it's about reaching new
markets and the audience is internal but
it's more often and going to be a larger
number of external users. So while we
might start with internal, the focus is
to get these assets out there to a much
larger external community and it's
really about less to learn and and speed
and consumption and that's really the
focus for APIs. So if you think about
these things working together, the
systems of record that are running each
of our businesses today are critical
systems that can't go down, need high
availability, high security. uh we're
going to have robust connectivity
capabilities and that was done through
an enterprise service bus like the IBM
integration bus. Big level of focus on
governance to be sure that we got the
services right and that we uh didn't
change them without concerned for all
the things that were consuming them
possibly breaking if we made a a bad
change without testing it correctly. So
systems of record absolutely critical uh
cannot go down high security needs lots
of governance. Now along come things
like mobile and social and big data and
analytics and and and these things are
moving at an incredible rate of speed
and I can't change the systems of record
at that kind of rate of speed. So to
solve this problem and let the business
do the things that they need to do
quickly, we're going to encapsulate
these systems of record services as
self-service APIs that someone could
sign up for and consume themsel. if
we're going to predefine the security
aspects and the terms and conditions
around that and make that available
through an audience and a secure gateway
that'll access these back-end systems.
And so the idea here is that the APIs
and services do work together. They're
not one is a replacement for the other
and the APIs will be accessing the
services from the systems of record, but
we can change these things and we can
create them on a much more rapid basis
and make these things available in a
self-service manner. So let's look at
what these things have in different have
uh as differences and not just what they
have in common. So most of the time uh
people who uh worked on services were
provider oriented services based on the
system of record. If you had a customer
system uh uh that had customer data
there might be one or more customer
services that people would access and if
you needed customer information you
would come to the customer service. So
it was a provider oriented service. Uh
same thing for the account, for the
inventory, for the shipping system. Any
of these systems might have services
that represented what the system did and
those would be uh services that you
would access to access those back-end
systems of record. The APIs are consumer
focused. And if you think about what a
consumer might do uh with the backend
services, they will uh access
potentially more than one service. In a
scenario, for example, where I want to
check my order status, I might have to
check the customer service, I might have
to check the inventory service, I might
check the system uh the the shipping
service all in one API call and not have
three separate APIs for that person to
do that. So, one consumer oriented API
might call three or more back-end
services to come up with the answer.
From an integration perspective, while
they both do uh integration, S SOA and
services were very focused on
integration and had a complete robust
set of connectivity capabilities,
integration is not really the primary
focus of APIs. We want to take an API
call and get it into the back end as
quickly as possible. It's about securing
that and making it perform very well and
and and uh and making it consumable.
It's not about complex integration. we
do need to do some integration to get
the API call to the back end. And so
that minimal amount is done as part of
the API uh solution. Uh why do you care?
Connectivity and reuse is what we talked
about for services. Self-service
consumption, security, analytics, and
speed for APIs. And finally uh for
services, the focus is uh for governance
is very strong. And for APIs, it's
really just enough. We need to be able
to move very fast in the API space to
get to market very quickly. So there is
a a difference in perspectives and use
cases for APIs versus services. And
really the best scenario is that we're
using these
together. So three questions lead to
good APIs. The first question you want
to ask yourself when you're thinking
about what API you want to create is who
is the audience? What what uh what
audience are we talking about? Is this
an internal uh user that is going to
build a mobile app or use it somewhere
inside the enterprise? Is this a
partner? Uh am I making a public API?
The second question, probably the most
important one, is what do they want? So,
we're focusing on that consumer. What do
they want? Not what do you have? We're
not going to put an API in front of
every service that we have and just say
to the audience, uh, you figure out how
to make these things work together. The
better APIs are going to be consumer
oriented and map to m potentially
multiple back-end services. It might be
the case that we're going to call one
one back-end service and that's fine. uh
but let's not focus on what we have as
the things that are driving the API
creation. And then the third question
that we're going to ask is under what
terms and conditions are we willing to
share. And this deals with the security
around the API, who's authorized to use
it and also the policies around the API
rate limits, how many times per minute,
hour, second, whatever it is that we
want to make it available. And so we'll
uh understand what conditions we want to
make this available to them. And that's
what leads to good APIs. After we've
answered these questions, of course,
then we have to build the API and we're
going to map the what do they want to
the what do we have? But that's not
something that should drive the creation
of the API
itself. So let's talk a little bit about
how microservices fit into this. Uh
traditionally every project that we've
done uh for the history of computing has
three components to it. uh there's some
kind of a user interaction in some way,
whether it's a user interface or
something that a user is going to
interface with the uh new project to
tell you what they want to do. Uh
there's going to be some kind of
business logic that they deal with that
is going to make uh the decisions on
what should happen and then maybe some
data manipulation on the back end, some
updates or some reads uh that are going
to get done to access and and uh massage
the data in some way. And as we did
these projects, we thought about it from
an endto-end perspective and we
delivered that project as a whole. Uh
and that would take a certain amount of
time to deliver whatever amount that
was. We needed all the parts to come
together to deliver the project
successfully. With microservices, what
we're going to do is do the exact same
thing, but we're going to break it up
into the component parts. So each one of
the parts the user interface the
business logic and the data manipulation
can be built separately by individual
teams on a separate schedule with the
idea that these will be working together
but also that others might use them as
well. So if you think about this a
mobile app uh let's say is being created
it has a user interface it's going to
call in and do some business logic and
do some data manipulation and maybe
that's the first solution you come out
with. But the second solution might have
the partner uh doing something that's
going to invoke that same business logic
and that same data manipulation. In this
case, you don't own the user interface.
Someone else does. And you can come to
market much quicker if you've built this
on microservices as an architectural
style rather than as a whole monolithic
project. And really, that's what the the
trend toward microservices is. Let's
think about the components that we can
build together um in consumable ways so
that uh we can uh do projects faster and
and still get great results uh for the
enterprise. So how does that work with
APIs? Uh so the microservices can be
built uh either in the systems of record
or in front of the systems of record
based on your needs uh and add the
business logic for the user interface if
you want to do that there for the uh
business logic and for the data
manipulation and then you'll control the
access to the microser through an API
layer that makes that microser
consumable by the audience that you want
to consume it. So if you're making it
available initially to the um internal
developers for the mobile app or the
web, that's great. And then you want to
make an API available to your partner to
consume that same business logic, that's
fine too. And you can have different
terms and conditions for each audience.
And so really that's how APIs and
microservices will work together with
the services in the systems of record uh
to provide a complete solution. And it
gives us a tremendous amount of
flexibility. Uh it gives us the control
and the the uh availability for the
systems of record while giving us the
speed and consumption and security that
we want from a uh an API layer. And so
think of an API as a managed micros
service and you're you're good to go for
bringing these things to market.
Hopefully that helped to answer this
question once or for all. I'm sure it's
not the last time I'll be answering it.
uh but uh I'll be pointing people to
this video so that they can see the
answer for uh positioning APIs and
services and microservices. Thanks.