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.

Services, Interfaces

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 GetterService, CreatorClient etc. 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 GetterClient or CreatorClient in the client code. I'm not sure, if i would confuse a future library client user by this pattern.

  • Random tip: the Visual Studio "paste JSON as classes" feature is magic for quickly creating a lot of DTO code
    – pjc50
    Feb 6, 2023 at 10:45
  • thanks, i knew that feature already. It is indeed quite handy
    – Michael
    Feb 6, 2023 at 11:15
  • How would this help compared with simply using HttpClient directly? -- learn.microsoft.com/en-us/dotnet/fundamentals/networking/http/… Feb 6, 2023 at 15:39
  • Allright, so here i made already some kind of a journey. I tried implementing a REST client using HttpClient as i was told, this is the correct way because you don't actually need external dependencies like RestSharp - i like that statement! BUT, it quickly turned out, that doing so it is quite hard to write unit tests and mock the HttpClient behavior. Therefore i switched to use a specific version of RestSharp (106.15.0) in combination with the helper utility MoqRestSharp.Helpers. That allowed me to mock all the behaviour of the RestSharp library in my tests.
    – Michael
    Feb 7, 2023 at 7:59


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Browse other questions tagged or ask your own question.