Andrei - Thanks for this question.
In general, <Entity>Ref should refer to an existing entity, so if you specify in API input a Ref that does not exist you are likely to get a not-found or some other return code (depending on how the designer of the API spec chose to handle this problem.
For cases where the designer foresaw a need to allow creation of a referred entity, we use the RefOrValue pattern, and this is made explicit in the API specs. For example, in the Product Order API (
TMF622_Product_Ordering_Management_API_REST_Specification_R17.5.0), an order item may be created to refer to an existing or a new product, so the reforvalue syntax is used, allowing the POST to contain a complete Product resource or just a ProductRef resource.
If you think that for a specific API you need creation of a new referred entity, please open a JIRA issue (if you have access), or put this on the feedback page for the API spec download (e.g.
tmf629-customer-management-api-rest-specification for Customer Management API).
------------------------------
Jonathan Goldberg
Amdocs Management Limited
------------------------------
Original Message:
Sent: Jul 05, 2018 05:10
From: Andrei Kolchanov
Subject: Nested Ref entities and resource creation
Hello,
I have a very basic question about nested Ref entities and resource creation.
Let's consider TMF629 Customer Management as example.
It is possible to POST customer json document with relatedParty or account attribute .
For example
{
"name": "Moon Football Club",
"account": [{
"id": "4600",
"name": "Paradise Account",
"description": "This account ...",
"href": "https://host:port/accounts/account/4600", "id": "4600",
"name": "Paradise Account" }]
}
Should system create customer with id 4600 in this case?
Is it a common rule for all nested Ref entities?
------------------------------
Best regards,
Andrei Kolchanov
Netcracker Technology
------------------------------