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.

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.

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 God awful 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.

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.