There are some good answers here, but I'm not sure that they will help you convince your coworkers. As many have pointed out, what you are suggesting is not a shift away from RESTful design, and I think that is key to getting them on board with your proposal.
REST is not about making sure your API only allows storing and retrieving data. Rather, it is concerned with modeling actions as resources. Your API should enable actions to be taken (it is an Application Programming Interface, after all). The question is how to model those actions.
Rather than coming up with a term, examples are probably the best way to explain this to your coworkers. This way you can show how they're doing it now, what problems this causes, a solution that solves the problem, and how it still remains RESTful.
Let's look at your Customer object.
The UI POSTs a Customer, but subsequent tables have not yet been updated. What if one of the subsequent calls fails because of an error in your UI code (or misbehaving browser plugin, etc)? Now your data is in an inconsistent state. It could even be a state that breaks other parts of your API or UI, not to mention that it is simply invalid. How do you recover? You would have to test for every possible state to be sure this wouldn't break something, but it would be tough to know what is possible.
Make an API endpoint to create customers. You know you don't want to have a "/customer/create" or even "/create-customer" endpoint, because create is a verb and would violate REST. So nounify it. "/customer-creation" could work. Now when you POST your CustomerCreation object, it will send all needed fields for a customer to be fully created. The endpoint will ensure that the data is complete and valid (returning a 400 or something if it fails validation), and may persist all within a single db transaction, for example.
If you also need an endpoint to GET /customer objects, that's fine. You can have both. The trick is to create endpoints that serve the needs of consumers.
- You guarantee that you won't end up with bad state
- It's actually easier on the UI devs if they don't have to "know" ordering of requests, validation concerns, etc
- It's not as chatty of an API, reducing latency of network requests
- It's easier to test and conceptualize scenarios (missing/malformed pieces of data from the UI aren't spread across requests, some of which might fail)
- It allows better encapsulation of business logic
- Generally makes security easier (because business and orchestration logic in UI can be modified by users)
- Will likely reduce logic duplication (more likely you'll have 2+ consumers of an API than 2+ APIs that give access to the same data)
- Still 100% RESTful
- It's potentially more work for the backend dev (but may not be in the long run)
It may be difficult for people to understand this paradigm and what is good about it if they haven't tried it out. Hopefully you can help them see by using an example from your own code.
My own experience is that once the devs on my team started implementing this strategy, they almost immediately saw the benefits.
This article from thoughtworks really helped me get the idea of modeling actions as objects using practical examples: https://www.thoughtworks.com/insights/blog/rest-api-design-resource-modeling
I would also suggest reading up on CQRS and Event Sourcing as they are concerned precisely with this sort of thing (i.e. divorcing your API from the actual persistence logic). I don't know how willing your coworkers would be to read this sort of thing, but it may give you more clarity and help you explain it to them.