API Facade Common Patterns: Data stubs & URLs
This time, we'll look at a couple more common patterns: data stubs and URLs.
In the same way we designed for errors with the facade unconnected to any back-end systems, you can stub out what response data would look like, and have the facade return that to you.
In the same way we designed the forced raise for errors, you can force the mock. Setting mock = true, you have a shunt in the facade that returns the stub. Again, we're looking at predictable behavior to do test driven development.
It's a good idea to only support the mock attribute on the test server and to raise an error if the mock parameter is included in production.
I think of the URL as the strongest affordance for a well-designed API. This is where the facade pattern begins to shine.
The goal is something like this - an app developer wants to do something as simple as see a collection of accounts by doing an HTTP GET on /v2/accounts. However, the internal system may be far more complex than /v2/accounts, like this Salesforce URL.
Doing URL mediation through the facade, you can show the developer on the outside the simple /v2/accounts interface while keeping the complexity of the internal system behind the facade.
Supporting limited clients
Here's a scenario to consider in the context of the URL pattern. Certain clients have limitations on the HTTP methods that they support.
Take for example a client app that doesn't support HTTP DELETE.
You can handle this through the facade by making the method an optional parameter. As the request comes into the facade, the facade changes the HTTP method from GET to DELETE. It also strips the method=delete query parameter and translates to original request of the backend system.
Next time, we'll finish our review of common patterns by looking at versions and data formats.