This document discusses the differences and relationships between APIs and web services. It argues that APIs are a superset of web services and the distinction is based more on business needs than technology. A single platform is needed to handle all aspects of API and service management, including publication, mediation and integration, monitoring and remediation, and lifecycle management regardless of the underlying protocols and standards used. Such a platform provides flexibility to support multiple protocols while simplifying development and management of APIs and services across their lifecycle.

1. Copyright © 2001-2012 SOA Software, Inc. All Rights Reserved. All content subject to confidentiality agreement between SOA Software and Customer.
APIs and Services
One Platform
or Two?

2. Common Misconceptions
• APIs and Web Services are distinguished by the
technology they use, JSON vs. SOAP
• APIs have become the external interface to an
organization while Web Services have become
components for internal collaborations

3. What is an API
• Has become a broader term than web service, it is
not exclusive to JSON/HTTP as some may lead us
to believe
• Can utilize different data formats such as XML,
SOAP, JSON, or plain text
• Can utilize different transports such as
WebSockets, HTTP, TCP, MLLP, JMS, or MQ
• Does not exclude Web Services, SOAP, XML, JMS

4. Differentiating through Exposure
• The choice of technology should be dictated by the
client:
– Web/JavaScript – JSON/HTTP, WebSockets
– Mobile – JSON/HTTP
– Java A2A – XML over the most relevant protocol
• You may need to expose multiple types depending
on the channel

5. Simplifying the Landscape
• APIs are a superset of Web Services – it is a
business differentiation, not a technical one
• You need a single platform that is flexible enough
to handle multiple:
– Transports and Protocols
– Message types
– Descriptors and Documentation Standards

6. Sample Topology

7. Common Challenges
• Publication
• Mediation and Integration
• Monitoring and Remediation
• Lifecycle management

8. Publication
• Publishing different types of APIs requires a
central location for all interface information
– Protocol
– Parameters
– Behavior
– Location
– Security

9. Publication
• A single platform can:
– Present different descriptor and documentation models
– Mediate between them: Swagger, WSDL, Schema, JSON
Schema
• A single platform can support a cohesive
developer community

10. Mediation and Integration
• Publishing an API often requires mediation:
– API is currently XML but clients also need JSON
– API is currently SOAP but client applications can benefit from
WebSockets
– Trust domains (Identities) may be different
– API uses OAuth but Service uses WS-Security
• A platform that supports mediation of a wide variety of
protocols provides a needed bridge between APIs and
Services
– Needs native understanding to eliminate custom coding

11. Mediation and Integration
• Publishing an API often requires multiple calls to backend
system to provide a single call to simpler client applications
• Speeds up API development to meet the needs of the
business
• Abstracts protocol and security from the API developer

12. Using a Gateway
• Brokers all communication between clients, APIs, and
Services
• Multiple protocol bindings can provide protocol mediation
• By supporting enforcement and implementation security
mediation can be performed
• Integration with multiple identity systems can support
multiple trust domains
• Data conversions can be performed with simple
orchestrations and transformations
• Aggregating multiple calls can be performed with more
complex orchestrations

13. Monitoring and Remediation
• Performance and failures are often driven by downstream
APIs and Services
• Root Cause Analysis
– With a common platform performance and failures can be
traced to their root cause
• Capacity Planning
– A single platform aids in collecting capacity information from all
dependent APIs
– Easily compare committed vs. existing capacity
• Throttling and QoS Managements
– A single platform utilizes throttling at different integration
points to ensure SLA’s are met at each level

14. Monitoring and Remediation
• Dependencies can be modeled from top to bottom
• Easier to find root causes of failures
• Consistency of metrics for all APIs

15. Lifecycle Management
• At their core, APIs and Services are both just software
• Templates and Standards
– Standards for the use of protocols, documentation, security
should be established and adhered to
• Best Practices
– Business justification, requirements gathering, dependency
management, integration testing, compliance testing should be
performed consistently for both
• Control
– A single platform can provide centralized control and reporting

16. Conclusion
• APIs are a superset of Services, albeit with more
business focus
• API standards are constantly evolving, so be
careful when investing in a constrained technology
platform (e.g. XML-focused)
• Irrespective of the standards, APIs need a single
platform for:
– Publication
– Integration and Mediation
– Monitoring and Remediation
– Lifecycle management

17. Thanks…
Alistair Farquharson, CTO, SOA Software
ajf@soa.com
www.soa.com
@afarqu
@SOASoftwareInc