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'.
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.