Considerations for decoupling and refactoring business logic to a REST API

Question

We've got a .NET Solution consisting of a MVC Website and a bunch of libraries for business and data logic. In the past the website was the only way to interact with our business logic, but we're finding ourselves having to share this logic between various systems, and we've decided to expose it via a REST API.

The typical flow of information between the current architecture is:

UI -> Model (Controller) -> Model (Business Logic) -> Entity (Data Logic) -> DB

If I were to move the business logic library into a REST API, obviously I need to retrofit the MVC website to consume it so we continue business as usual.

Should I leave the existing method signatures on the business logic as they are, with the model objects as the parameters, or should I consider refactoring this?

public List<ClaimSearchEntity> Search(ClaimSearchRequest request)

Here's something to give an idea of the dependancies between the layers:

MVC.App -> Application.Logic
Application.Logic -> Application.BusinessLogic
Application.BusinessLogic -> Application.Data
 -> Application.Models
Application.Data -> Application.DataLogic
 -> Application.Entities
 -> Application.Mappings

Something else I thought might be helpful in this regard is returning meta data for the API requests by exposing the model fields as JSON. Something like JIRA does.

I need to find a balance between getting the job done quickly and getting it done properly. Do you have any suggestions or alternatives for my approach?

• Bart van Ingen Schenau: If you have correctly separated all concerns between your libraries, then creating a new REST interface to your system should be not more than putting a second MVC.App next to the existing MVC.App that provides the web-UI. All libraries below that level should be unaware of which application is calling them.

Answer 1

Your business logic should remain untouched. The Rest API is a view. The UI is a view. At most the controller should change to accommodate this change. In an ideal design the controller would have no knowledge of any views and wouldn't change at all.

Rather than showing the flow of information it would have been helpful to see the directions of dependencies of these components. All the names tell me is what the responsibilities are. Not how they may be teased apart.

• Daniel Minnaar: I'll update my question to reveal the dependencies. "In an ideal design the controller would have no knowledge of any views and wouldn't change at all." - This got me thinking. Do you propose another layer between the controller and the logic? Something that manages the transfer of information between the controller and wherever the logic is? Perhaps an abstraction of a API Comms layer?
• candied_orange: I'd like to see the UI and the Rest API user talking to the same API that doesn't know about either of them. If you can make that API the Rest API itself awesome (now the UI talks to the rest API). But I suspect you don't want to go breaking a working UI just yet. If so you might consider a layer that will make the rest API talk to what the UI currently talks to, the controller. If the current design was done well this shouldn't break the UI.
• Daniel Minnaar: Oh, you mean moving the existing controllers into the API and going straight from web pages to the API?
• candied_orange: I'm assuming Application.Logic = Model (controler) and MVC.App = UI. What I meant was that a view needs an API to talk to. You can regard the rest API as that API. But that would break a currently working UI (MVC.App). As you are currently architected your UI (MVC.App) talks to something, an API, that I assume is Application.Logic = Model (controler). You could regard the Rest API as a view and have it talk to Application.Logic = Model (controler). That way your current UI and Model (controler) don't change. You just suddenly have something else that talks to the Model (controler).