MVC and RESTful API service

Question

MVC is pretty straightforward. There is a Model, a Controller and a View. When we create a website, it all come together as 'client sends REST keyword request to server -> the server matches the requested URL to the controller action -> which then calls the model(s) for data gathering/processing, gets the result -> and returns the result back to the client as a HTML page (view)'.

What if we are talking about a pure RESTful API web service? Then the flow with be something like 'client sends REST keyword request to server -> the server matches the requested URL to the controller action -> which then calls the model(s) for data gathering/processing, gets the result -> and returns the result back to the client in JSON'. Same as before, but there is no 'view'...or rather, the generated JSON can be thought of as a 'view'. In a sense, we are only utilizing the MC part of MVC. Is that how it is should be done? Or are there any other, better-suited patterns for a API-only service instead of MVC?

Answer 1

MVC is a paradigm from the Smalltalk world concerned with how object orientated systems could have UIs.

Early web frameworks took the general idea (separate out business logic, controlling logic and view logic) and applied the principle to how they structured the web application. Before this it wasn't uncommon to have a mess of HTML generation code inside domain objects, or business logic inside HTML templates (think very early PHP)

The thing is that the original MVC from the Smalltalk world isn't really what MVC is in most web frameworks. A HTML output isn't really a "view" in the sense that Smalltalk understood a UI screen to be.

So that is the first reason not to get too hung up on whether you are following MVC properly. Hardly anything is. Take it less as a strict division and more a guideline of Hey wouldn't it be nice if our HTML templates weren't full of business logic.

Secondly MVC is just a way of structuring server side code. It really has nothing to do with REST/HTTP. REST is concerned with how clients and servers communicate. It doesn't care if the representation the server sends to the client is in a HTML template that took a lot to construct with a templating engine, or a JSON object that was one call in the controller.

If you don't think your server needs a "view" layer, that is fine. You will still gain benefit separating out your business logic (ie model) from the controllers that are handling a specific HTTP request, even if all the controller does it call a JSON parsing call on some object and return that data.

Answer 2

View is a layer responsible for displaying information which may be interpreted by a user/client of your application (it does not say the user has to be an actual person). JSON is completely valid format for a view layer, computers understand that.

As long as the view layer publishes information which can be used by a user to affect models in your application, it does not matter how the view looks like, it is still a view, a layer acting as a middleware between the user and the system.

Answer 3

MVC is pretty straightforward.

Martin Fowler would, perhaps, disagree with this:

Different people reading about MVC in different places take different ideas from it and describe these as 'MVC'.

Moving on...

When we create a website, it all come together as 'client sends REST keyword request to server -> the server matches the requested URL to the controller action -> which then calls the model(s) for data gathering/processing, gets the result -> and returns the result back to the client as a HTML page (view)'.

OK, this is a bit of a tangle

MVC, whatever it is, is a collection of ideas for implementing user interfaces.

REST is a collection of architectural constraints for building out large scale applications.

The web, which is what you are talking about here, is a giant document management application built using most of those same constraints.

The similarities you are seeing between the two are (take your pick) incorrectly attributed, or superficial.

RESTafarians have a common understanding of HATEOAS, "hypertext as the engine of application state", and that should send alarms ringing through you head -- why would a view be an engine of state? If we question the premise, and look for additional evidence, we might also notice two odd things.

First, that we can take the HTTP server completely out of the equation by loading the HTML from disk. The browser is perfectly content with this, excusing some minor variations in behavior that may arise from the change in base url. Views don't generally continue to work when they have been completely disconnected from the model and controller like that.

Second, if we observe a modern browser carefully, we'll notice that there are multiple views of the HTML. Multiple views of a view seems like a really strange idea, but sure enough there's the main presentation, with a bunch of text markup that responds to user gestures, and then there's this "Source View" thing that shows the raw HTML and also responds to user gestures. It's turtles all the way down!

The answer to the riddle, of course, is that the HTML isn't the view. The collection of widgets in the browser are the view, and they are in communication with the Document Object Model, which was initialized by reading the HTML.

In other words, the HTML is a representation of state, just like Roy T. Fielding promised.

What if we are talking about a pure RESTful API web service...? Same as before, but there is no 'view'

More correctly, same as before: there is no view. The JSON, just like the HTML, is a representation of state, suitable for crossing process boundaries.

Think "DTO" or "Message" and you're inferences will be much less likely to lead you astray.

Answer 4

Is that how it is should be done?

Passing the JSON as a view, or using it as a view model to construct the view does not violate the pattern.

I am using the same architecture in the current application I am working on and it is working very good. Together with some nice JS framework you can create some really responsive designs.

Or are there any other, better-suited patterns for a API-only service instead of MVC?

Honestly, no idea. But I think that whether you use MVC or not in an API is not that important. Use whatever you find convenient. When talking about web services there are a lot more important aspects to consider (which are not directly related to MVC), e.g. security, consistency, availability, etc.