0

Generally speaking, is it acceptable for a web MVC application to use REST endpoints for it's data access layer? I realize this would make practically every request cost 2 requests and that doesn't sound nice. What I don't know is if this is a "valid" or commonly used approach.

  • 2
    MVC is a UI pattern. It should lie on top of a Domain Layer, which itself lies on top of a Data Access Layer. The business logic goes in the domain layer, which does not need to know where the actual source of the data is from. Your question specifically concerns the DAL, and it doesn't really matter whether you use MVC at the UI layer or not. – Vincent Savard Jun 6 '17 at 16:41
  • 1
    That being said, whether you should expose the data only through a web service or access the database directly is more of an organization concern, in my opinion. If you're part of a large organization where multiple teams need access to the same data, then maybe it is worth to expose the data only through a service and have a single team responsible for maintaining this service. If you're the sole developer and you only have a single project which requires access to this data, then I believe it would be overkill to do so. – Vincent Savard Jun 6 '17 at 16:43
  • 1
    realize this would make practically every request cost 2 requests. Why 2 requests? One for navigation and other for data retrieval? – Laiv Jun 6 '17 at 18:18
  • 1
    That's because the MVC (frontend) and its state is managed at server side. MVC can be isolated totally as a single app at client side. Like movile apps do. Angular for instance allow you to do it through states or routes. – Laiv Jun 6 '17 at 18:35
  • 1
    Any chance to decouple the frontend (and its management) from the same app that holds the API? – Laiv Jun 6 '17 at 18:48
2

is it acceptable for a web MVC application to use REST endpoints for it's data access layer?

Yes, why not? As soon as you can keep the REST API stateless. The frontend (MVC) can be stateful if needed. This is somewhat the kind of web applications we have been implementing during the last decade.

Independently of the framework, to me, the key is to keep separated the frontend (MVC) from the backend (API). And, when I say separated, I say totally separated. If possible as different applications. Or at least, as different modules.

MVC at server-side

If you are planning to use Spring Boot + Spring MVC this is probably the approach in your roadmap.

It's important here to keep separated the web contexts too. We can achive this being methodic with the RequestMappings

MVC web context:

@RequestMapping("/myapp/web")
@RequestMapping("/myapp/web/home")
 ...

API web context

@RequestMapping("/myapp/api")
@RequestMapping("/myapp/api/users")
...

Or literaly with two different web contexts.

MVC web context:

@RequestMapping("/my-mvc-app/...")
...

API web context

@RequestMapping("/my-rest-api/...")
...

Why separated web contexts? I have find the security to be easier to configure working this way. Plus, we may decide to work with cookies in one of the contexts, both or none.

Once defined the web contexts (or subcontexts) it's time for the security. For multiple security configurations, take a look here. Remember to make stateless the security of the API.

  • Pros : Spring provides you with everything you need for the MVC. You barely have to reinvent the wheel. From security to view exporters, Spring will do all the hard work for you.

    Probably it is the approach we are more familiar with (overall for those that come from the traditional Java EE)

  • Cons : Spring MVC allows you to send the model alongside the view in the http response. So, the calls to the API for rendering the view become (almost) unecessary. The usge of the API is reduced to asynchronous calls for enhancing the view, with the inconvenient of the MVC session (stateful) remaining unaware of the changes produced by the API. So the view should refresh the state of the MVC. How? Reloading the page. Finally, the double security. Do you remember that API and MVC have different security configurations? Due to the API and its security are stateless, the MVC session doesn't​ grant you access to the API :-).

Note: Someone may say that the API and the security don't need to be stateless. Of course, if everything is stateful we make things easier... In the short run

MVC at client-side

This is probably the approach that best suite with rest APIs. After all, it's exactly how movile app works.

The MVC is isolated in the client-side application. From the navigation to the security (server-side security aside). Models, views and controllers too.

A significant complication of the approach is to deal with CORS.

One trick is hosting the client app within the Spring Boot application. Placing the client app (mostly static context) in the static folder

/src/main/resources/static

  • Pros : High grade of deocupling, which translated into project management jergon means: Easy to parallelize the SDLCs.

    Translated into software engineery jergon: No framework lock-in, we are free to implement MVC, MVP, MVVM or any other pattern, server-side is simpler now and the interaction between server and client is less convoluted. Easy to test. Easy to scale out, due to the server-side​ is totally stateless.

  • Cons : A whole new universe of frameworks, tools, libs and headahes are waiting for you. Sometimes you will feel like reinventing the wheel. Dealing with CORS is tedious. The fallacies of the distributed computing suddenly hit you in the face as never before.

I realize this would make practically every request cost 2 requests and that doesn't sound nice.

Not necessarily​. Remember that Spring MVC (approach #1) also has "Model" and returning a model in the http response saves all the API calls addressed to the rendering.

What I don't know is if this is a "valid" or commonly used approach.

There's not such things as:

  • common approach
  • common solution
  • better solution
  • valid approach ....

Only approaches (solutions) that best suite your requirements, needs and preferences.

1

Yes, it is acceptable. I am currently making an application that does this.

However, you should have a good reason to do so. In my opinion, it is preferable to have your MVC application not use a rest end point for data. Using a rest end point decreases performance, and raises technical complexity.

While using a rest endpoint will decrease performance, it should be negligible if both servers are located in the same physical network. I think the greater cost is the additional coding and maintenance required.

There are three primary ways to design your rest data API:

  1. Output models are based directly on your DB schema

  2. Output models are based on your business entities (the persistent properties of your logical behavior model)

  3. Output models are based on your view models (what your application needs to display)

I would suggest to you, if you do go the rest route, to avoid basing the data api on your view models (#3), as this detracts much of the re-usability gained from a rest api.

But, most important to avoid is, having an ambiguous output scope... that is to say, decide whether your api will be doing 1, 2, or 3, and then, stick to it!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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