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.
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:
API web context
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
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.
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:
Output models are based directly on your DB schema
Output models are based on your business entities (the persistent properties of your logical behavior model)
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!