API CRUD Anti-Pattern in action

Last Update: 31.10.2018. By Jens in Newsletter

It’s one of the emerging Anti-patterns regardless of REST or not. If you got an API you might step on it. We covered the REST version in an older email before, so today I’ll focus on the effects I on an implementation I reviewed yesterday.

In this case, they build an internal API for use in their portal applications (Spring Boot). The main purpose of the API is to hide away the old legacy data hub (stores contracts, etc) and provide a central business logic for the new portal applications. So far, so good.

Unfortunately, this API was database table driven, so for each table, there were a couple of endpoints working with that table. Just over HTTP instead of SQL.

In the clients, those calls were bundled to accomplish the actual business goal. For example: to show the user his contracts, the client was getting some backend-id for the user, requested all contract relations for her and then fetched the contracts, one by one sometimes.

This burdens the client and causes a few problems:

• business logic outside the API
• the client must know the internals of the API to make sense out of it
• more requests over HTTP than necessary, thus lowering performance

In a use case centric way, this example could have been one call - fetch the damn contracts for the user. Instead, it was 3+ calls and a lot of unnecessary knowledge in the client.

Think in use cases and you got fewer problems :-)