Open APIs

 View Only
  • 1.  Depth and Expand Directive

    TM Forum Member
    Posted May 25, 2023 09:24
    Hello Everyone,
    We want to implement depth and expand directive for TMF637 GET/List operation which will be enabled for consumers to read product resources.
    Entities such as ProductRelationship, ProductCharacteristic contain all the attributes (expanded resources). Entities such as BillingAccount RelatedParty are the  references and contain id, href. 
    We want to expand BillingAccountRef entity and return all the possible attributes in response of GET/List operation.
    REST API Guidelines 3.0 part 2 has a section detailing how to use depth and expand directives.
    However, we have some doubts regarding the actual implementation  of these directives.
    We can expand up to the level of depth using the depth parameter and narrow down the expansion of referenced object using the expand parameter.  
    Taking in consideration the guideline examples, we can have something like:
    GET /productInventory/product/ =billingAccount
    To have the actual implementation, shall swagger file of TMF637 need be adapted to have entire definition of possible resource(here, billingAccount) or is there any other way to provide reference of BillingAccount object(part of TMF666) in TMF637?

    Thank you for your help!

    Kanchan Kalani
    Proximus SA

  • 2.  RE: Depth and Expand Directive

    TM Forum Member
    Posted May 28, 2023 03:01

    Hi Kanchan
    The published Open API swaggers do not contain the schemas for expanded entities. If you know for sure that you will want to expand, and that your codegen needs the expanded entity, you might consider using the <Entity>RefOrValue instead of <Entity>Ref. This will bring the full schema of the referred entity into your swagger (and as a side-effect will make your swagger very large :( , so be careful).
    Hope it helps

    Jonathan Goldberg
    Amdocs Management Limited
    Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.