For a simple web application, I am designing web services to expose the application functionality (mostly data storage / retrieval, but also data processing). As the application is not too complex, I am rather looking for a pragmatic approach to design rather than strictly following a specific pattern.

However, I am wondering how to design my services:

  1. Data-oriented, so that each entity / business object has its own endpoint / service handling all the CRUD operations etc.

  2. Goal- / Role-oriented, so that each service fulfills a specific "need" of a specific role to accomplish a certain task.

To illustrate it with a small example: Let's say I am building a small product catalog where users can browse products and download user manuals / information sheets / ... while an administrator can edit them.

Data-oriented approach

Following a data-oriented approach, I would build two services:

ProductService
FindProducts - to search for product
ListProducts - to get all products
DeleteProduct, UpdateProduct, AddProduct

ManualService
FindManuals - show manuals for a specific product UploadManual, DeleteManual

In this case, both the administrator and the user would use both services (even though users would never call any of the methods changing data). So distinguishing between user / admin would only happen on a permission level.

Also, in order to show a product page, the user would need to call two different services: ProductService to find a product and ManualService to retrieve the manuals belonging to the product.

Goal-Oriented approach

On the other hand, following a goal / role oriented approach, I would focus on the tasks needed for each use-case:

ProductDisplayService
FindProducts - to search for product
ListProducts - to get all products
FindManuals - show manuals for a specific product

ProductAdministrationService
ListProducts - to get all products
DeleteProduct, UpdateProduct, AddProduct
FindManuals - show manuals for a specific product
UploadManual, DeleteManual

In this case, there would be a clearer separation of concerns: The ProductDisplayService contains everything (but not more) to display products while all administrative concerns are hidden in a separate service (ProductAdministrationService). At the expense of maybe some duplication (because administrators also need to see all data of course).

In addition, this would simplify implementation if some information should only be shown to the administrator (e.g. date of last change). In the data-based approach, the implementation would need to dynamically filter this data from the result while the goal-oriented approach would only require endpoint-based authorization.

Question

Personally, I have a tendency to prefer the goal-oriented approach as it more clearly separates concerns. However, current trends in service design (such as REST and microservices) seem to strictly favor data-orientation.

Are there any best-practices I should be aware of?
Or especially reasons why data-orientation seems to be more common? Or am I simply not understanding REST / microservices correctly in this context?

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Browse other questions tagged or ask your own question.