There are many misconceptions about the differences and similarities between APIs and Web services. In this presentation, we explain what an API is, what it does, and how to leverage a unified enteprise architecture.

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

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