Biggest pain point is every organization has their own implementation details about the REST-like (or not) API, payload structure, paging, rate limits, error ha

Biggest pain point is every organization has their own implementation details about the REST-like (or not) API, payload structure, paging, rate limits, error handling, etc. There is no solution to this, if someone comes up with yet another standard it will just be yet a different way people will implement things [0]. A woodworking analogy: API's are the glue between applications, sometimes its a nice dovetail joint between the apps with a little glue and a lot of craftsmanship and things fit nicely. Sometimes it looks like Homer Simpson built it after a 12 pack of Duffs with glue all over the place and maybe a rusty bent nail holding things together. In the end it doesn't really matter since you are usually forced to integrate with an API so you just deal with the varying levels of quality. Here are some things to not do (and how to deal): - Error responses in HTML (have good handling for when JSON.parse fails) - Missing/incorrect documentation on some endpoints (call the API and iterate to see how it responds) - When changing API versions, change the ID of the things in the API (scripts to update old to new ID's, feature flag what ID to use, add yet another column to a table like v4_id) [0] https://xkcd.com/927/ https://xkcd.com/927/