是否应该在 RESTful API 中使用视图

Question

I guess this is relative to API's best practices. I am looking at implementing API and not really sure if I need to use views in API design or leave them for user's frontend implementation. I don't think is a good idea to implement views in API, but it would be nice to know what usually is done. I think API calls should always return either JSON or XML; adding views complicates everything...

Do you use views in APIs, yes/no, why?

Answer 1

API stands for Application Programming Interface. It is something exposed by your app that can be called to interact with it. REST is a philosophy which does not tell you how to design your application, just defines a communication structure (resources, representations, verbs, nouns).

A view is not a concept in REST, but in the most common case, a view will be a representation of a resource in REST. Although this view representation can be directly returned by the server, most developer prefer to return only the data and separate the visualization.

If your API returns HTML, that would not violate REST, but it would introduce coupling between the user interface and data of your application. I recommend that you don't do it, not because of REST, but because you'd violate basic software design principles.

Answer 2

For my REST APIs only JSON data. In REST APIs you must return JSON or XML because your API needs to be indenpendant of the frontend implementation.

Answer 3

The view you are suggesting is only the html kind of view. But a view can also be in json, xml and so many other types.

View is a representation of the resource. Is the way you export the data processed by your application.

Thinking like that, u will notice that even and api project can use MVC.

There are a couple of gems to work with views on an api project like: rabl and active_model_serializers .

Answer 4

The answer is yes and no. A REST API that outputs simple machine-parseable format (XML, JSON, CSV) doesn't need views, but it helps API users, if they can see the output in a human readable format, so they can use it to verify the output of their application consuming the REST API. It also a valid option, if you minimize code duplication by handling data processing in the model, and you have separate views for a JSON/XML REST API and another for human consumption. In this case, the "view" transforms the objects created/retrieved by the model to various output formats to various consumers -- both human and programmatic.