Conceptualizing RESTful API endpoints as views in the MVC design pattern [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.

---

开发者_开发技巧

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 6 years ago.

Improve this question

As I am trying to describe a system I built in a research paper, I came across the following notational problem when trying to represent the complexity of the system I created:

• Assume I engineer service A, communicating with the world solely through its RESTful endpoints. Then, I engineer service B, that uses service A as its backbone and represents its data to the external world.
• Assume that service A has its own models and data controllers. Should then the RESTful endpoints be conceptualized as views in the MVC pattern?
• Assume that service B has its own set of proxy models that map more or less directly models of service A. It provides a set of GUI views to the users, with a completely separate set of controllers. Where does service A come in the MVC? Should it be represented as an encapsulated model?

Real world example (not related to the problem I am working on) would be:

• del.icio.us and pinboard.in provide roughly akin set of APIs, and thus can be swapped as a service A for service clients (for the purposes of question assume they are both built upon MVC pattern, but may have completely different sets of models and controllers)
• Delibar is an iOS app, and thus follows the MVC schema and matches requirements for service B; assume Delibar models its data after the data models of service A as represented in the API endpoints.

Are thus pinboard.in and del.icio.us the model for Delibar? Are RESTful endpoints the views? And are thus the view sets for pinboard.in and del.icio.us the same?

---

Endpoints are actions/operations on the Controller. Views are the data (HTML, XML, JSON, or otherwise) returned by the controller in response to an HTTP GET request.

Service A is not represented as part of the MVC triad of Service B, since MVC deals with the Interactions against the Model and selection of Views by a controller. Service A is accessed though the Data Access layer of Service B. If you are using an "Active Record" pattern, then queries or changes to the Model by the Controller in Service B will be passed through to the data access layer by the Model itself. If you are using a Domain Service / Data Mapper / Repository pattern, the controller will call out to this layer which encapsulates Data Access.