Shared database vs tightly coupled message model

Question

We have an ASP.NET MVC application sitting on top of a MySQL database. Now we're thinking about creating a public REST API so that third parties may integrate their services with ours.

Now, I would much prefer not to have the API application access the same database directly. I like the idea of an application that "owns" it's own data. Making an internal change in the web app´s data model would inevitably affect the public API as well:

However, the only alternative I can think of, would be to set up a message bus and have the two applications communicate through that. So when some external client requests a piece of data from our public API, the API would then create a message on the service bus which is then handled by the web app, which then responds with the desired data. If we go with this design, the web app would be the only application that accesses the database. And we might use different patterns of information exchange over the service bus, such as request/response as in this examples, or pub-sub for stuff like "something has happened".

Now, to make sure the message types are consistent in both applications, I was thinking about putting them in a separate assembly, and have the two applications consume it as a Nuget package. However, this would kinda bring us back to square one, because now both applications are tightly coupled to this shared object model. And even If we use practices like semantic versioning, I fear it will be a source of much frustration and a lot of extra work.

Any comments on this? Perhaps there is a completely different architecture that would fit our needs better?

EDIT:

I should point out that the service bus I'm talking about would not be an ESB, but rather a simple message queue.

I must say I'm quite puzzled by the lack of articles and blog posts on this subject. It seems nowadays every SaaS out there has an outwards facing API, so there should have emerged some best practices by now.

Answer 1

I agree that web app must be the only one accessing mysql. So web app must inevitably provide some sort of api that let your public web api access relevant data. This API is a contract between web app and mysql that allow them to be developed separately without breaking.

The complexity and flexibility of this API must reflect your business needs but keep it as simple as possible. If you can, stick to a simple REST API or whatever is easiest to integrate and document with your framework.