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
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
