3rd Party API Consumption

Convener

Chris Busse (@busse)

(add your names here)

Reasons

Contract consolodation - turn five Google Maps Enterprise contracts into one, with key injection at the gateway
To be able to later change/swap the 3p service without requiring client apps to change
Total Abstraction - devs may not even need to know about 3p API behind the scenes

Documentation Needed

Straight Proxy (1:1) - Document the security changes then link to the 3p vendor docs - but if 3p docs are poor, this is an opportunity to improve them for your use
Abstraction - needs documentation, it is essentially your API at this point

Metadata Considerations

Data fields that explain the abstraction
Message format could carry meta data identifying source in systems that abstract multiple sources - this allows sources to be evaluated (quality, etc)

Talking to 3p Services

Aggregators and Standard Formats

MISMO - Mortgage industry standard for message exchange given as an example
Shipping Vendors / ConnectShip given as an example that has already done and productized the aggregation
Aggregation -> You develop to the aggregation standard -> but then you may be likely to still abstract that!

Additional Considerations

If using 3p API, does user or app authenticate?
Is your aggregator enterprise scale (just because the services behind it are doesn't mean the aggregator has done their due dilligence/perf testing)
Is aggregator agile enough to keep up with changes from services they're aggregating?
...and can your org in turn react to those changes?
To an end user it isn't a 3p API - it is your app!

"3p APIs are like installing a furnace in your house" - Mike A.

Challenge in the API world is that we're building so many services on top of each other

...versioning & release cadence...

When you provide APIs you take on this responsibility

Sidebar: We need more testers at these conferences! @TODO: Link to Lorinda's future blog on the testing topic