|
|
|
|
|
by jonesetc
2461 days ago
|
|
At my job we have what I'll call an approximation of one of these command based APIs, looks like a classic RPC API. We also have a set of internal user procedures that are basically those escape hatches you mentioned. They are the source of almost every odd and problematic behavior we encounter in our normal API. I believe presenting slightly more open commands for internal use is the right idea, but sliding all the way to an arbitrary entity edit API is a quick way to break state expectations. Yes this could also be solved by having perfectly crafted constraints in the business logic and/or DB, but what's more manageable? Managing a few extra specific APIs, or having every expectation perfectly defensively coded? |
|