No - the REST API doesn't need anything special for you to interact with our business logic, or any object you create inheriting from our base business logic class.
We did introduce a IJiwaDTOSerialisable interface which expects you to implement the methods DTO_Serialise() and DTO_Deserialise() - but nothing requires you to implement that - you'll see in our REST API plugin the code for GET, POST and PATCH operations on Sales Orders, Inventory and Debtors that we invoke the DTO_Serialise() or DTO_Deserialise() methods, but we did that simply as a convenience to reduce the code in the plugin, and so people wanting to write their own custom routes could just use our DTO_Serialise() or DTO_Deserialise() without having to manually set properties.
For instance, If you use a decompiler to examine our DTO_Deserialise() (in for instance, the inventory business logic), you'll see it's simply parsing the DTO supplied and setting properties of the business logic - a lot of mundane code we didn't see much use being in the plugin, so we opted to put that in the business logic. It's your choice to follow the same pattern or not with your own business logic objects. I would recommend implementing IJiwaDTOSerialisable, though.
We might leverage the IJiwaDTOSerialisable interface in the future - like we did with the IJiwaSerialisable and IJiwaDeserialisable interfaces - to allow the Desktop application UI to have the base form know how to export / import to / from XML automagically without the UI doing or knowing anything special. So you may see soon an Export and Import DTO group appear on the ribbon of forms to allow XML/JSON/CSV import and export functions from the UI - which might be confusing as we'll have two XML imports and exports - legacy XML and the new DTO XML - but we'll work something out to make things clearer.