An API (Application Programming Interface) is the means by which third parties can write code that interfaces with other code. A Web Service is a type of API, one that almost always operates over HTTP (though some, like SOAP, can use alternate transports, like SMTP). The official W3C definitionmentions that Web Services don\'t necessarily use HTTP, but this is almost always the case and is usually assumed unless mentioned otherwise. For examples of web services specifically, see SOAP, REST, and XML-RPC. For an example of another type of API, one written in C for use on a local machine, see the Linux Kernel API. As far as the protocol goes, a Web service API almost always uses HTTP (hence the Web part), and definitely involves communication over a network. APIs in general can use any means of communication they wish. The Linux kernel API, for example, uses Interrupts to invoke the system calls that comprise its API for calls from user space. Conceptually, SOA- and API-based IT infrastructures accomplish a similar end goal: creating an IT architecture that abstracts consumers of services from the applications and technology that deliver the service. In either case, IT subtly shifts from focusing on delivering technology and letting the business figure out how to use it, to working with the business to deliver a series of services that are then combined to accomplish an objective. Both SOA and APIs purported to focus IT on delivering consumable services related to a business process, and each used largely the same technologies to make it happen. To some extent, SOA mirrors integration efforts of years past, where access was created on an as-needed basis, and generally only between trusted and well-known partners. APIs mirror the development that\'s occurred on the public internet, where everyone from payment processors to the postal service has provided open APIs, and allowed developers to access and use them, often with little more than a brief signup process. SOA and APIs have more similarities than differences, but a good architect will evaluate both for best fit. SOA business process oriented, where API is business function/feature oriented. Both have to be managed, secured, and monitored -- in other words: governed. SOA may use one or many APIs, but it\'s not so common for an API to use an SOA. SOA represents a complete solution to a business problem instead of function. API functions can be used by applications in any number of ways, including inappropriately. The same is less likely with SOA because of its process orientation. Both SOA and API are valid design options. Both will be around for the foreseeable future. The fact that there is an ongoing debate is a testament to the value of both, but I do lean toward SOA. Solution An API (Application Programming Interface) is the means by which third parties can write code that interfaces with other code. A Web Service is a type of API, one that almost always operates over HTTP (though some, .

1. An API (Application Programming Interface) is the means by which third parties can write code
that interfaces with other code. A Web Service is a type of API, one that almost always operates
over HTTP (though some, like SOAP, can use alternate transports, like SMTP). The official
W3C definitionmentions that Web Services don't necessarily use HTTP, but this is almost
always the case and is usually assumed unless mentioned otherwise.
For examples of web services specifically, see SOAP, REST, and XML-RPC. For an example of
another type of API, one written in C for use on a local machine, see the Linux Kernel API.
As far as the protocol goes, a Web service API almost always uses HTTP (hence the Web part),
and definitely involves communication over a network. APIs in general can use any means of
communication they wish. The Linux kernel API, for example, uses Interrupts to invoke the
system calls that comprise its API for calls from user space.
Conceptually, SOA- and API-based IT infrastructures accomplish a similar end goal: creating an
IT architecture that abstracts consumers of services from the applications and technology that
deliver the service. In either case, IT subtly shifts from focusing on delivering technology and
letting the business figure out how to use it, to working with the business to deliver a series of
services that are then combined to accomplish an objective.
Both SOA and APIs purported to focus IT on delivering consumable services related to a
business process, and each used largely the same technologies to make it happen.
To some extent, SOA mirrors integration efforts of years past, where access was created on an
as-needed basis, and generally only between trusted and well-known partners. APIs mirror the
development that's occurred on the public internet, where everyone from payment processors to
the postal service has provided open APIs, and allowed developers to access and use them, often
with little more than a brief signup process.
SOA and APIs have more similarities than differences, but a good architect will evaluate both for
best fit. SOA business process oriented, where API is business function/feature oriented. Both
have to be managed, secured, and monitored -- in other words: governed. SOA may use one or
many APIs, but it's not so common for an API to use an SOA.
SOA represents a complete solution to a business problem instead of function. API functions can
be used by applications in any number of ways, including inappropriately. The same is less likely
with SOA because of its process orientation.
Both SOA and API are valid design options. Both will be around for the foreseeable future. The
fact that there is an ongoing debate is a testament to the value of both, but I do lean toward SOA.
Solution

2. An API (Application Programming Interface) is the means by which third parties can write code
that interfaces with other code. A Web Service is a type of API, one that almost always operates
over HTTP (though some, like SOAP, can use alternate transports, like SMTP). The official
W3C definitionmentions that Web Services don't necessarily use HTTP, but this is almost
always the case and is usually assumed unless mentioned otherwise.
For examples of web services specifically, see SOAP, REST, and XML-RPC. For an example of
another type of API, one written in C for use on a local machine, see the Linux Kernel API.
As far as the protocol goes, a Web service API almost always uses HTTP (hence the Web part),
and definitely involves communication over a network. APIs in general can use any means of
communication they wish. The Linux kernel API, for example, uses Interrupts to invoke the
system calls that comprise its API for calls from user space.
Conceptually, SOA- and API-based IT infrastructures accomplish a similar end goal: creating an
IT architecture that abstracts consumers of services from the applications and technology that
deliver the service. In either case, IT subtly shifts from focusing on delivering technology and
letting the business figure out how to use it, to working with the business to deliver a series of
services that are then combined to accomplish an objective.
Both SOA and APIs purported to focus IT on delivering consumable services related to a
business process, and each used largely the same technologies to make it happen.
To some extent, SOA mirrors integration efforts of years past, where access was created on an
as-needed basis, and generally only between trusted and well-known partners. APIs mirror the
development that's occurred on the public internet, where everyone from payment processors to
the postal service has provided open APIs, and allowed developers to access and use them, often
with little more than a brief signup process.
SOA and APIs have more similarities than differences, but a good architect will evaluate both for
best fit. SOA business process oriented, where API is business function/feature oriented. Both
have to be managed, secured, and monitored -- in other words: governed. SOA may use one or
many APIs, but it's not so common for an API to use an SOA.
SOA represents a complete solution to a business problem instead of function. API functions can
be used by applications in any number of ways, including inappropriately. The same is less likely
with SOA because of its process orientation.
Both SOA and API are valid design options. Both will be around for the foreseeable future. The
fact that there is an ongoing debate is a testament to the value of both, but I do lean toward SOA.