I work on a React app consuming RESTful API. My API on top of basic CRUD operations exposes business functions falling under controller archetype (executable functions, with parameters and possibly return values). E.g.:
http://api.example.com/carts
http://api.example.com/users
http://api.example.com/documents
http://api.example.com/carts/{id}/checkout
http://api.example.com/users/{id}/block
http://api.example.com/documents/{id}/print
Within the team however we have disagreement regarding how API access layer should be called. We struggle to choose between *Repository and *Service.
On one hand these functionalities can be perceived as some collections abstractions and facades and it make sense to call them repositories. On the other hand however they expose some business, domain logic which definitely does not fall under repository pattern and is definitely a service.
Normally (in the back end) a repository could be either a service dependency or can be used standalone. Repository serves the purpose of accessing and modifying a collection, while a service is facade for some more complex business operations.
This separation however does not seem to make a lot of sense in the front end, where the only difference is the API endpoint website will call. Thus it's pointless to separate them, since realistically they are within the boundaries of the same concern.
What are your opinions about it? What kind of nomenclature do you use in your apps? Thanks for help and suggestions ;)
Aucun commentaire:
Enregistrer un commentaire