Is the SOLID principles applicable to API:s

Question

I have built an (web) API with a couple of endpoints, which in turn have a lot of CRUD-operations. The code itself conforms to the SOLID principles. Now I have a consumer for that API which states that if they use my API it will break the SOLID principles on their end because my API provides more functionality than they require.

It makes sense regarding Interface Segregation Principle.

ISP splits interfaces that are very large into smaller and more specific ones so that clients will only have to know about the methods that are of interest to them.

Let's say that I have an API which manages customers. It has methods for Creating, Reading, Updating and Removing customers. But the consumer doesn't need to Update or Remove. Should I then create a new API which omits methods for updating and removing? And thus only provide methods which are of interest for the consumer?

For example, if you're going to use the Facebook Graph API it will most likely provide more features than you need. Does that mean that you break the SOLID principles when you use it?

Answer 1

Using an API should not lead to breaking any principles unless the API is severely broken. If some API has more features than needed in some application, which is quite normal, it's always possible to hide the API behind a restricted custom interface in the consumer end. Problem solved, if there ever was one.

However, if your API has a lot of consumers and those consumers could have conflicting interests, then it's probably wise to consider splitting the interface so that interfaces are only shared between consumers with similar concerns. It's best to avoid situations where a change to the API needed by some consumer leads to unwanted changes in dozens of consumers. This is the rationale behind ISP.

Consumers that need nothing but read and find operations will typically have different interests than consumers that need to alter the data. Having a consumer that only creates and reads entities is probably not the most common scenario.

Answer 2

Most interfaces that have multiple consumers (beyond "Use" vs "Test") will have some methods not used by every consumer of the interface, that doesn't mean those methods should be excised, because the extreme end of that would be one interface per consumer, and no methods in the intersection.

Conceptually Update (Value -> Value) covers Create (Nil -> Value) and Delete (Value -> Nil), so you could argue for a readonly API and a read/write API.

Tell them to write a thin wrapper that just exposes CR and hides UD if they want to be picky.