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?

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.