Search code examples
apidesign-patternsarchitecturesoftware-design

What is the counterpart (pattern) to services on the client side?

Let's say i do have a service, which is just a REST-API. This rest api provides some data.

As far as i understand, which makes sense, I can encapsulate data, which is sent from and to this service into DTO's. This totaly makes sense, since you'll have some business objects but often you'll need to serialize them in a way. So as far as i understand this would be a generally accepted and know way to abstract it regarding this part.

Then this DTO's are sent trough the REST-API. Regarding the server side it seams pretty straight forward, having some controllers which provide the data or receive them, I'm not seeing any issues there (at least for now).

So regarding my question. On the client side there are objects, which will access this API, this object, in my implementation contains a http client (not sure maybe i decouple them from this objects) and also it contains methods to access the api. So in one way or another, abstracting the use of http client and accessing the API away.

HOW DO YOU NAME THIS OBJECTS ACCESSING THE API?

I'm now naming them XXXManager/XXXHandler/..., but this names feel far to generic and i feel like there has to be some convention or pattern for this? Naming them XXXService also does not feel not completely right, because service for me is like the server side part, this object are accessing the service.

So how would you name this kind of objects and are there some deeper patterns to handle this kind of service/api accessors?

Solution

  • The model/pattern that would work here, is a classical layered architecture, which works like that:

    • The HttpClient should be wrapped around a class (let's name it ApiClient) that exposes methods for accessing the REST API. In each of those methods, the httpClient is used to execute the HTTP call.

    • There is a layer of Service/Manager classes that use the ApiClient and also apply their own business logic.

    • There is a layer of UI components which also inject the Services/Managers to grab the data and render it on the UI.

    In this way you decouple the layers, which improves both the scalability and the testability of your code.

    The naming somehow depends on the type of the client-side implementation/framework that you have.

    If you have a web-frontend client, then the name TransactionService would tell me that this class talks to some external transaction service (Service is not a naming tied to server-side components).

    This naming model applies to Angular, for example.