Look at any mature framework (Django, Laravel) and either use that or emulate it.
Why?
REST and GraphQL deal with discrete resources. yes, GraphQL can deal with many, but it's still an abstraction to group calls.
In my experience, I'm dealing with user input that does not map cleanly to resources. Ultimately, if you persist things, of course resources are affected. But the input is its own world.
The sign REST/GraphQL abstractions are breaking is when you create ad-hoc endpoints/entry-points to serve these resources.
Classic example would be a call to "copy 5 widgets from Y category to Z category".
In resource-oriented world, you could do:
1. PUT/POST for each widget, changing the category label sending the full resource.
2. Or you could write an ad-hoc endpoint that accepts more than 1 widget, repeat as above.
3. You still need to figure out the "proper" way to handle the category. If Z doesn't exist, do you make them PUT/POST to /categories/ to create one first? Or do you auto create it for them? How do you auto create it? Does the category field accept the primary key of a category and arbitrary text in case you're creating a new one? That's odd.
4. So on and so forth.
How would I do it in Django world, at least?
1. Create a view, it will have 2 forms on the view and process them together.
2. Form 1 is a formset with a row per widget you wan to copy. Any number of rows can be sent. Django will validate they are valid widgets.
3. Form 2 is a form with a "from_category" and a "to_category" as well as a "new_category_name".
4. Form 2 has a validation rule, if to_category is null, new_category_name must have a label for a new category.
5. In the view, process Form 1 and 2 together, if valid, handle a create everything.
The difference is subtle. But you're decoupling input from resources. I yearn for an API-centric way to do this.