I'm coding amateurishly both API (Ruby) and frontpage (Vue3) for a personal app. API exposes a model (Person) witch "has_one" of other stuff (like Info, TaxInfo) and "has_many" of Addresses, Phones, Emails, etc. Frontpage GETs the data and displays it. In the screen the user can see and edit at the same time the parent model and some of its children (using Vue3 components). The user changes what he likes and presses "save" button. Then frontpage must send UPDATEs to API and API does the changes and returns possible validation errors.

A. Frontpage decides which models have changed and sends UPDATEs to API for each of them. This way API may do some more SQL SELECTs because each child UPDATE must go through its parent (or shouldn't it?) and needs authorization.

B. Frontpage creates a JSON of what has changed and UPDATES with it the API Person model. The update method in Person controller: B1. updates the models by itself and returns validation errors or B2. redirects to children controllers and gather from them validation errors (I don't know yet how to do that but I believe I can find the way). This option may leed to complicated controllers in Ruby API.

C. Something else (please describe)

Which is the best approach in your opinion?

CodePudding user response：

In my opinion, if you're going to have separate apps for your UI and API then your API shouldn't be built with assumptions of how the UI behaves. It should be more generic and reusable so that you can make changes to your UI without having to refactor your API. With that set, I would go with your first route - your UI knows what can be updated on a given page and dispatches the appropriate requests to your API.

CodePudding user response：

From my point of view partially generated GUI is possible if you use real REST APIs with HATEOAS and metadata attachments something like RDF Hydra something more vocabs like schema.org. In that case a form is just a hyperlink with parameters and it can be generated based on the hyperlink description. The same with hyperlinks and other content. The hard stuff is what you do with the response, on which panel you display it, does the client add extra logic to it, etc. So a client cannot be completely generated unless it is relative dumb, but it can be partially generated and if you have a good framework, then the rest can be filled out easily. Currently I don't know of such clients mostly because most API developers don't fulfill REST constraints like uniform interface and HATEOAS, which makes it hard to generate universal clients. As of your problem, it does not make sense to develop a REST API if you don't have multiple different clients e.g. a mobile app and a single page webapplication for desktop. Normally REST is not used this way, it was invented for webservice to webservice communication, it can be layered and each layer does a small task, so it can be scaled pretty well and you can separate the services by topic too and make microservices, which is another way of scaling it out and you can have aggregating services, which call multiple services on lower levels. So it has a pretty flexible structure from this perspective. Doing frontend - backend communication is okay with it if you know what you are doing.