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:

Shared database access

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".

Tightly coupled object model

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?


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.

  • The public api is interacting with your service (webapp), so the pub. api should point to your service, not the db which is behind the service.
    – cdosborn
    May 4, 2015 at 3:33
  • @cdosborn Agree. But what would be the best way to achieve this? I'm not overly crazy about building a new API inside the web app only to server the public API. I would rather turn it the other way around, and have the webapp call the public API to prevent code repitition. But I'm not completely sold on that either. I'm sure there must be a better way to do this.
    – johnknoop
    May 4, 2015 at 11:26
  • Without knowing the details of your application, I would extend webapp with public api to hit the same functions as your service. Then make the main webapp query the api.
    – cdosborn
    May 4, 2015 at 14:45

1 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.

  • So what you are saying is, we should set up an internal API hosted within the web app, that our public API may consume?
    – johnknoop
    May 3, 2015 at 22:13
  • Yes, based on the described system, an ESB is way too complex for the task, you just need to consume the web app data within an internal application. May 3, 2015 at 22:20
  • I wasn't really thinking of an ESB, but something more along the line of Azure Service Bus. The bus is really just a message queue without any orchestration.
    – johnknoop
    May 4, 2015 at 9:26
  • I don't know Azure Service Bus and how well it integrates with .Net. This could be a good choice but it is more complex than a simple API. So I can't see why it's required in this case. Maybe with more precision about the future of the application, the accepted amount of maintenance and development, the expected workload to process,.. Everything that can be a blocker to one or the other solution May 4, 2015 at 10:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.