How to turn a 403 into a 202 at the API Party

The Challenge

API design looks easy right? Lots of material, methods and examples to look at. However, we've not been on a team that hasn't struggled to build a clean interface for their consumers. From unconventional use of status codes, difficult to parse responses to endless debates about what to name endpoints. This is coupled with iteratively built API's, which potentially realise value and feedback earlier but may suffer from inconsistency over time.

Gwen and Ash believe that testing can help to overcome some of these challenges through some common patterns, that they've identified through experience:

• 3 Amigos - being part of the conversation early and often, with the right people, based on not just the implementation but the wider impact on adjacent systems.
• Test First - creating the right level of tests before implementation together can expose inconsistencies in data and structure. Documentation up front means that the API is usable by other teams before it is even written.
• Exposing Complexity - designing the tests first can help expose issues with chaining multiple requests which may be a symptom of an overly complex architecture.
• Scalability - identifying areas that need to be extremely scalable and those that don't by leveraging domain knowledge.

How it will help

By testing first, common errors with API design can be flushed out quicker, even before the code has been written. Design and architecture should not be left to the developers and architects, by following some of these guidelines, as a Tester you will be able to contribute to a consistent, transparent and maintainable API.