This document summarizes episode 2 of the API Facade webinar series, which discusses common patterns when implementing an API facade. The episode covers errors, stubs, URLs, versioning, data formats, and integrating internal and external systems. It also includes a question and answer section where attendees ask questions about these topics.
Report
Share
Report
Share
1 of 49
More Related Content
The API Facade Pattern: Common Patterns - Episode 2
1. API Façade: Common Patterns
Episode 2
Webinar Shorts
March 2012 Series
Brian Mulloy Apigee
@landlessness @apigee
5. Webinar Shorts - March 2012 New!
Episode 1
The API Facade: Overview
Tuesday, March 6th
Episode 2
The API Facade: Common Patterns
Tuesday, March 13th
Episode 3
The API Facade: Technology
Tuesday, March 20th
Episode 4
The API Facade: People
Tuesday, March 27th
6. Episode 2 Topics
• Recap: API façade
• Errors
• Stubs
• URLs
• Versioning
• Data formats
• Internal & external systems
8. App
App
Developer
API Facade
Content
Big DB Management JDBC RSS
SOAP
System
9. One Big Problem
1. Build up from systems of record
App
XML XML
XML
XML XML XML
1.
Objects Tables RSS RSS Tables RSS
Content
Big DB Management JDBC RSS
SOAP
System
10. Three Small Problems
1. Design the Ideal API
2. Implement Design with Stubs as Façade
App 3. Mediate between Façade and Systems
Developer
1. Ideal Design
2. API Facade
3.
Mediate
Content
Big DB Management JDBC RSS
SOAP
System
13. When I say errors, you say test-driven development.
14. Errors
200 201 304 400 401 403 404 500
{“developerMessage”:“Verbose, plain language description
of the problem for the app developer with hints about how
to fix it.”,“userMessage”:“Pass this message on to the app
user, if needed.”,"errorCode":12345, ”status":401,
“moreInfo”:“http://dev.teachdogrest.com/errors/12345”}
Request Response
API Facade
nothing to see here
15. Errors
GET /products?raise=500
(don’t support raise in production)
Request Response
API Facade
nothing to see here
16. Errors
Request Response
404 Not Found
API Facade
449 Retry With
Big System
26. Versioning
Fast App Slow App
Developer Developer
/v3/accounts /v2/accounts
27. Versioning
GET /v2/accounts GET /v3/accounts
Request
API Facade
GET old.internal.com/accounts GET new.internal.com/accounts
Big Old New Untried
System System
36. Q&A
Should the version number appear in the URL immediately
after the domain name or is it better to have application name
after domain name? Billing accounts /accounts/v2/create?
37. Q&A
With all the shunting you suggest make for a terrible complex
layer?
39. Q&A
How can a GET request be transformed to a SOAP POST,
specifically when the SOAP POST request size is huge?
40. Q&A
What about version in the request header instead of putting it
in the URL, what would the drawback be of using it in the
request header?
41. Q&A
Should every response follow a standard format that contains
errors, if any, along with response body or should the response
body change based on success or failure of the operation?
42. Q&A
What is the functional difference between the raise and the
mock parameters again?
43. Q&A
For the API I am hosting façade pattern makes sense, but for
the external systems where I am consuming APIs, factory seems
more appropriate. What’s your take?
45. Q&A
Get flash accounts should return all accounts right? Wouldn’t
want to prevent this, what would a URL request look like? If
you’re reflecting a response from the database where the
state=Washington, how would that work?