Service granularity

The notion of service granularity describes what functional level will a service address, rather high level like an entire user or very details like a specific attribute of this user.

A highly granular service will split the interactions into low level functional blocks, whereas a standard service will provide richer and more complete interactions, but not splittable.

For instance:

• A service that manage the product catalog including product categories, stock, etc. This would be a low granularity service

• A highly granular service would just be the stock information. The name of the product. Etc. Everything is split in small high granularity services, that can either be assembled on the service side as one low granularity service, or let the client assemble these high granularity services itself. For the use case of mutualized logistic flows, we could have a specific service on "routes" without any information on what is transported. Another service on orders, to find out what was ordered. And then have a view that combines the different services.

Some pros and cons of each approach:

	Pros	Cons
High granularity service	- Easier to maintain and debug - Less data being transmitted as only what is needed is requested - More flexible and future proof - Easier autorisation management	More services to keep track of
Low granularity service	- Less service calls - Easier to develop - Performance gains when it comes to assembling data via for instance joints at the DB level	- Services are more complex and difficult to maintain - Often requires ad-hoc development when new usage appear

The main advantage of highly granular services in the context of interoperability with authorization management is the simplicity of development on the server side. For instance it is easy to answer in an interface that the owner of some data denies access to it for a specific client. The service will just use the standard HTTP responses (401 or 403). This becomes more complex if this entity is nested in another (as for a low granularity service). In this case, the server will respond well to the interface with the root data but will have to express one way or another that its answer is not complete because it lacks a part for which the user has no rights.

Conclusion: implement the needed low granularity services for phase 1 and in phase 2, implement in addition more granular query based services.