apologies, if my question is to trivial. But i after doing some research i couldn't find an appropriate answer to this seemingly simple question. As a developer with some experience, i know that i just could "code it down". But i'd like to create REST sharp library, that is easy to understand, maintainable and testable.
Let's say i have a simple CRUD REST-API with the following methods
- get items via GET (with a string based filter)
- create items via POST
- delete items via DELETE
- update items via PATCH
The server supports eight different types of items. The server returns items and accepts new, by using serialized JSON objects. The items all have some base properties, that are the same (like: id, name description). Of course the specific items also have different properties. Here i think, it's quite easy to implement a base item, that is inherited by all specific items.
This is the point where i have a lot of uncertainty. Instinctively, i would create a service with an appropriate interface, that "houses" all the methods for all the method types. This is, where i hesitate a bit. If i create a service like this, i would end up with 32 methods for each
server method x item type and a lot of code.
I was wondering, if this could be done in a smarter way. Would it be the better way, if i create a service (and interface) for each server method? Like a
From the "seperation of concerns" perspective that would make somehow sense for me, as i'm creating a service for each concern. But from the client perspective it feels somehow weird to use a
CreatorClient in the client code. I'm not sure, if i would confuse a future library client user by this pattern.