How do web services and databases relate to each other?

Question

The idea that web services are small pieces of functionality or data that are combined together and encapsulated as small, stand-alone objects is pretty clear and makes sense. But how do services relate to the databases that they use or provide an interface to?

For example, when moving from a monolithic two-tier architecture with a massive database that processes everything up to a service-based architecture, how does the database affect? Is the database divided into smaller databases and each of them is connected using a service, or is each service just interacting with the original massive database?

In addition, if the database is divided into, say, a service for user authentication and product information, where will a many-to-many object exist that tracks product views per user in the original massive database?

Answer 1

Simply put, "it doesn't matter."

Depending on what suits you.

At the API level, DB services do not exist, and this is just an implementation detail.

If the API is executed correctly, the database implementation should not “leak” through the client API layer.

As soon as you reach this level of the API, you can leave the database “as is” (if it is functioning, executing, supporting, etc.), or you can start breaking everything up at once, or gradually.

Obviously, a database break will have its own problems and problems.

So, I would start with services and their APIs, and making sure that you and your customers are happy with these. Only this process can make your decision for you.

Answer 2

I think Martin Fowler has an interesting lesson on this topic in the article "Thawing the database" (be sure to read, I would say!):

If you enable the protocol integration from SQL to HTTP, now means that you can modify the database from is the database integration in ApplicationDatabases. This change is profound .... If you integrate HTTP it doesn’t matter how the application stores its own data, which in turn means that the application can choose a data model that makes sense for its own needs.

Thus, the switch "from DB to WS" will allow you to take more care of your data. There is no need to adapt everything first to fit into the relational model, but you could use other models, as well as a key / value store, a graph database, or a document-oriented approach. - Whatever is best for the domain. Of course, in many cases it can be a combination of different models.

Answer 3

I find Will Hartung's answer to be almost perfect, but I would include a special case of ETL (Extraction, Transform and Load).

This integration pattern is sometimes used in the context of WS and includes a WS call (sometimes routed or organized by the Enterprise Service Bus (ESB)) to retrieve data directly from the database.