Should i use one update route or multiple for each business logic functionality
A good heuristic to use for anything "REST" - think about how it would work as a website.
Let's suppose we have three business processes we are interested in (buy-a-car, sell-a-car, update-registration). We could create an interface to those processes that is a single web page with one form on it that can handle inputs to all of the different processes.
But we're a bit more likely to have many different forms (much like a bureaucracy has many different paper forms specialized for its different processes) -- see Task Based UI. The landing page would have a bunch of links to help the client navigate to the specific form that they want.
So we have three forms on the front end, and three business processes in the back end. Does that imply that we also have three resources in the middle? and three controllers?
There's not a lot of difference between having three resources, each of which is the entry to a different process, vs having one resource that thinks about the payload and chooses the appropriate process.
In particular, notice that the client doesn't care which way things are implemented (the customer is submitting the form, assuming it will go to the right place), and the browser doesn't care which way things are implemented (because the metadata of the form tells the browser what the target URI should be).
Web caches care a little bit, because the resource identifier of the request tells the cache which previously cached responses should be invalidated when the form is submitted. (That's a very coarse summary, review the HTTP Caching specification if you need to get into the weeds).
What this tells us is that, for caching purposes, we want the target of the form submission to be the most important document that gets changed as a result of successfully processing the form.
It might be, for example, that we have a single web page that shows the client's entire fleet of vehicles, and each of these business processes will cause the representation of that web page to change -- therefore, we consider sending all of the form submissions to the same resource, because that's the most important one to update in all three cases.
But it's a trade off - we get smarter cache behavior, but the cost is somewhat more complicated request routing code (some of which we may need to implement ourselves, depending on the sophistication of the routing code that is being used and our willingness to adapt to it).
It's not wrong to go the other way - imagine a write-only resource that is a list of form submissions to be processed. Because the resource identifier is unique to processing that specific flavor of form, routing is trivial -- but general purpose caches aren't going to know to invalidate other relevant cached responses.
(Not entirely - see the HTTP Caching specification, but as far as I know we don't have a general purpose mechanism to communicate arbitrary response invalidation to caches. Linked Cache Invalidation stalled, and I haven't found a substitute that is doing better.)
Note that, ultimately, REST and HTTP don't have anything to say about "controllers" - controllers are an implementation detail hidden behind the HTTP facade.
Your web framework, on the other hand, may have severe opinions about how your controllers MUST be arranged to match a particular resource model.