First, I’ll talk to E10 exclusively. The tech stack on E9 is pretty different obviously but the patterns hold in 9 as well.
Be careful not to confuse BOs and REST vs WCF vs legacy 4GL network calls. A BO is just a class that does SalesOrder or Jobs or ARInvoices. There are methods on it to populate data for a search (GetList) or populate a forms tree with all it’s child records (GetRows) or to Update data, etc. That’s the same ‘SalesOrderSvc’ class no matter how the class is called across the network.
In WCF, that call comes in and the WCF plumbing does a (pseudo code of course)
var bo = new SalesOderSvc();
bo.Update(dataset);
In Rest, that call comes in and the REST plumbing does a
var bo = new SalesOderSvc();
bo.Update(dataset);
The same biz logic is being called so the same BPMs are firing, the same Method and Field security is in place, the same UD columns are added to the payload, etc. The only difference is how data is being serialized over the wire.
The Epicor SDK is focused on two major areas in regards to this chat. The first is the open ‘open source’ client code. You can see how everything is put together there. The other aspect of the SDK is the creation of new services using the tooling we use internally. Need to build a new ‘Dentist Office’ vertical and need to build some new services to manage Xrays machine output or whatever and need new services? There you go. Defined new db tables, services, the methods, the datasets, etc and it looks like a real E10 service - because it is - right down to automatically being exposed as a WCF and a REST service. You create the ‘DentalXraySvc’ class and the ICE framework does all the work exposing things for you. The app service coder doesn’t need to worry about the difference. If you have needs to lock that down in Method or Field security, license it as a partner, etc - all available to you in the SDK.
As to preference, the existing Rich Client forms (winform), EWA, most of the legacy clients - Service Connect, Info Worker, EMA, a few others still use the WCF client stack. Even Search and Social use WCF but do a v0.1 flavor of REST on WCF so I still count them as WCF. Everything coming out of late - Mobile CRM, Active Home Page, Epicor Data Discovery use the released to all v1 of REST. They are all using versions of the ‘Kinetic’ browser client announced during Insights 2018.
If and when we decide to move other clients to REST or Kinetic is not announced. By the way - that is two different things as well. Our rich clients COULD talk to the server via rest and stay in winforms. Again, REST is just a wire protocol for throwing bits over the wire. We don’t rewrite servers or clients when you flip from net.tcp to https for example.
As to preferences on which tool to use…
It depends on what you are doing. If you are doing a one off client or integration, the REST client is ‘simpler’ to use. You can use Postman for development and build an integration test suite in it. When a new release of Epicor comes out, re-run the test suite and check impact (and yell at us if we broke something and did not call it out in the release notes).
The REST services do not have the equivalent of the adapters, client BOs (impls), retry logic, session handling, etc.No UI framework until you get Kinetic in your hands (it’s exclusive to partners only atm though that will change at some point - SDK owners? General github repo? No clue atm). All the ‘broadcast tower’ context handling of the client, off the shelf BPM handling info messages, etc.
So you need to understand what you are trying to do before deciding on which tool to use.
Not sure that helps or confuses more.
FYI - internally we sometimes joke about a partner building a dental office vertical to try out ideas upon that fictitious company - think Fabrikam in Microsoft land. I am still waiting for the day we have a partner start building a dental office vertical and mess up all our straw man examples