My company developed a RESTful API that is used by a few internal applications. This API allows clients to charge one-time payments as well as recurring payments. Both of those things are made up of resources; a person needs a payment method to create a subscription that will create a transaction. The data is very relational, but one of our workflows is as follows.
Suppose a new person is looking to set up a recurring payment. Our workflow looks like this:
- Create a person
- Create a payment method linked to that person
- Create a subscription linked to that payment method
- Create a transaction that is linked to that subscription
Each of those operations is represented by an endpoint on one of our controllers that make up our application's REST API.
As the app has grown, many people are questioning why we are so steadfast in sticking to this modular API design. Any time a new client needs to integrate with this application to create subscriptions, they need to implement code that follows those four steps. Our answer has always been, "good software design, and REST, promote separation of concerns and keeping the construction of one type of resource separated from another allows us to keep things flexible and maintainable". The main counterpoint to this is that, like all software, we've had some bugs arise in between steps of this process and people argue that our problems would be solved (or less troublesome) if we had one endpoint that did it all.
The project is a few years old and has seen a good deal of production use. I'm very reluctant to believe that one "do-all" endpoint is the right thing to do but I feel like all I have to stand on in this debate is theory and principles. Some of our issues would likely have been solved by reducing the chatter between systems, but something seems inherently wrong with putting a bunch of distinct operations into one method and calling it a day.
Is there something I'm missing? Am I maybe biased because I helped design the app up to this point or are the other developers sacrificing maintenance and design in order to solve today's problems?
I'm hoping this question doesn't get closed as "primarily opinion based" because I'm looking for some answers grounded in real-world experience rather than theory/opinion (since I already believe that I, in theory, am right).