So maybe I can provide a little clarity on what we intended to solve with REST from the tools development perspective. When we built out REST v1 the mission was to make our existing APIs easier to get at using a REST interface, but not to try and solve the much larger surface of - how do we make super easy APIs for each business object.
So what REST is for us is a RESTful-ish veneer over the existing APIs which makes it significantly faster to get started with integrations, makes simple things like querying out BO data simpler to get at, and in a limited way makes API integrations against the OData a bit more resilient to underlying ERP changes since you can send and pull partial data you need. But it’s not all candy and roses - from a tooling perspective we can’t automatically solve making complex APIs which we have thousands of into simple to use APIs. To do that someone has to carefully redesign each one. So under the rest veneer all of the same data validation, sequencing, etc that’s baked into that very large set of services is still in play in the same way and we intentionally provided the direct mapping POST methods. So we provide generated swagger & odata $metadata that describes the services, but generally speaking our complex business object services have logic too complex to express in that fashion. Fields aren’t just required they’re required when x, but not y. Records can be saved only after certain other actions have taken place so there’s multi-api-call-sequencing that matters. That’s what ui trace is good for - understanding the sequence & details in which the ERP Client uses the existing BO services.
So all that said you should use rest for the reasons you enumerate - it’s the same api you’re hitting when in WCF there so that’s not really any easier you have to figure out the same complex sequence of events for the same complex business objects in the same way. WRT mapping to OData it is not always 100% possible to do so and sometimes you will need to use the custom methods (aka the direct business object api). Update in odata in particular as everyone has noted maps to UpdateExt. These are generated methods that attempt to simplify updates to a BO and sequence events - how well these services encompass the full scope of behaviors in the direct API varies and may not always be appropriate so sometimes you do need to call one of the custom methods.
Here’s my 2c on GraphQL - We think the GraphQL is niceand it’s built with a lot of the same problems as OData in mind namely that it helps build a lighter payload, be more resilient to underlying changes in the API, and has good query semantics. We might add it eventually as an option, but for the moment we think OData is solving the same set of problems for us and we have more important harder things to solve in the API that would get you all more value such as api keys with imbued security (maybe), standard oauth2, improved metadata and swagger, better help, import/export services for bulk operations, custom facade services to let you craft your own updateExt type of simple services atop the complex apis, etc.