I'm trying to write a REST API client for practice and I'm having trouble figuring out how lay out the project.
The approach I'm taking right now has
Requests, and a class that deals with authorization and headers and such (
CoreClient) that exposes a generic
DoPut<T>(string address,T item) and similar verbs.
UpdateRecordCode (contains logic)
UpdateRecordCodeRequest (entity, holds a record Id and a list of things to add to it)
Question 1: How do I determine which classes should implement interfaces - and what interfaces I should have in the first place - and which should inherit?
My best guess so far is that
Actions should inherit from an
ActionBase because each
Action is basically a kind of
DomainObjects should probably implement something so that they're consistent, but I'm not sure what.
The trickiest part is
Requests; ideally, I'd like other parts of the application to handle Requests generally, such that I could, in the UI, have a list of Requests a user might choose. I've tried this both ways, but keep going back to a concrete class as both feel weird. Interfaces, for example, end up with having to say something like
IRequest<UpdateRecordCode<UpdateRecordCodeRequest>>, which seems silly.
Question 2: Am I just doing this wrong? I feel like everybody's written a dozen API clients - I've written a number with minimal planning - but I'm trying to do this "right" this time around and it's, well, hard.
I know there are many duplicates of the "Interface or abstract class?" question, but I think this is distinct from those as it's about how they work together rather than simply "X or Y?"