Hacker News new | ask | show | jobs
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?