Hi Mike,

Quote Originally Posted by Mike Peat View Post
The REST Library assumes that you will have a structure that basically first lists the items for a given resource (say "customers"), then allows you to navigate to (i.e. provides a link to) detail of that resource, then within that there may be dependant resources, with a link to those. The structure is naturally List --> Detail --> List --> Detail, etc.

....
....
....

RestAPIObjects... yes, you can have 1..n cRestApiObjects in a given resource handler. It needs at least one. In the above scenario you would have a customers cRestAPIObject, linked to the oCustomer_DD, a contacts cRestAPIObject, linked to the oContacts_DD (which would have as a DDOServer the oCustomer_DD and a Constrain_File of Customer.flie_number) and a delivery addresses cRestAPIObject, linked to the oDeliverAddresses_DD.

Let's look at the code for that. I added Contacts and DeliveryAddresses to the OrderEntry sample, both relating to Customers (in a copy of the workspace I called CliveDemo).
Thanks for the detailed explanation and demo sample source. This has been a tremendous help and sorted many of the hurdles I was experimenting with.

Quote Originally Posted by Mike Peat View Post
That's not exactly what you are asking for, but I think it does the same stuff.
...
...

Instead of .../customers/contacts/11, you have .../customer/11/contacts giving you a list with a drill-down to details.
This works for me. I just had the elements back to front. I got something similar working this afternoon with the sacred texts.

Quote Originally Posted by Mike Peat View Post
PS - All Ozzie addresses were supplied by Google Maps; all Ozzie postcodes were totally made up!
I'd say that was a darn good effort .

(Perth=6000, Bunbury=6230, Bruce Rock=6418)