REST API - Subentities

[Tom-Vroemen]

Hi,

I just started working with DAB and am encountering an issue when attempting to create a customer -> customer address structure within the REST API.

I have created two entities, one named 'customers' and the other called 'addresses' (both of type "view") and used the "relationships" node to match them based on corresponding ID fields.
What I was expecting was a format as follows:

{
    "value": [
        {
            "id": "00000000-0000-0000-0000-000000000000",
            "Code": "0000",
            "Name": "Customer name",
            .......
            "Addresses": [
                {
                    "id": "00000000-0000-0000-0000-000000000000",
                    "Customer": "00000000-0000-0000-0000-000000000000",
                    "AddressLine1": "Address 1",
                    "PostalCode": "Postal Code 1",
                    .........
                }
            ]     
        }
    ]
}

However, it returns just the 'customers' entity:

{
    "value": [
        {
            "id": "00000000-0000-0000-0000-000000000000",
            "Code": "0000",
            "Name": "Customer name",
            ...........
        }
    ]
}

I have set the relationship as follows:
Customers -> Addresses

"relationships": {
        "addresses": {
          "target.entity": "addresses",
          "cardinality": "many",
          "source.fields": [ "id" ],
          "target.fields": [ "Customer" ]
        }
      }

Addresses -> Customers

"relationships": {
        "customer": {
          "target.entity": "customers",
          "cardinality": "one",
          "source.fields": [ "Customer" ],
          "target.fields": [ "id" ]
        }
      }

I have also tried using linking.object instead but I received the same result.
My question is as follows, is it possible to create this and if so, how?

[yorek]

In DAB, REST API does not support relationship navigation. If you want to take advantage of relationships you need to use GraphQL (which is a REST operation anyway, more specifically is a POST operation).

The reason behind this decision was that REST should be simple and not re-invent the wheel (and yet another standard). If people really want to do complex stuff with REST, we'll need to evaluate the adoption of OData as additional protocol. Otherwise GraphQL should cover pretty much all the use cases.

[Tom-Vroemen]

Hi yorek,

Thank you for your response!
Unfortunately, this is not the answer I was hoping for, but it is helpful nonetheless :).

I'll have a look into the GraphQL documentation and have a look if it is a viable option for us & our clients.

Thanks!