Open APIs

Expand all | Collapse all

TMF 685 Resource Pool Management is relatedParty. href is mandatory attribute ?

  • 1.  TMF 685 Resource Pool Management is relatedParty. href is mandatory attribute ?

    TM Forum Member
    Posted 8 days ago
    Hi All,
    I want to implement TMF 685 Resource Pool Management API. I was going through the documentation provided on the TM Forum Open APIs.
    The API specification documentation says href for related party in POST as well as PATCH operation is not mandatory for both Reservation API and Resource Pool API. All the examples in this document do not have href included in thier sample requests. Also it is observed in other TMF APIs that href is usually not mandatory attribute in POST requests. However it is observed that href is included in response in most of the cases.
    In conformance document for TMF 685 Resource Pool Management API it has mentioned href is mandatory attribute for related party, if relatedParty is included in POST as well as PATCH operation for both Reservation API and Resource Pool API. However it is not mentioned if above statement is applicale for request or response or both.

    Please clarify if href should be included in the POST REQUEST for both Reservation API and Resource Pool API or it can be skipped. We are already providing id, role and name for related party id in the request.


    ------------------------------
    Ketki Mujumdar
    IBM Corporation
    ------------------------------


  • 2.  RE: TMF 685 Resource Pool Management is relatedParty. href is mandatory attribute ?

    TM Forum Member
    Posted 7 days ago
    @Jonathan Goldberg and @Kiyotaka Mizuno could you please help me on this    ​​​

    ------------------------------
    Ketki Mujumdar
    IBM Corporation
    ------------------------------



  • 3.  RE: TMF 685 Resource Pool Management is relatedParty. href is mandatory attribute ?

    TM Forum Member
    Posted 6 days ago
    Hi
    As a general rule, we have stated that href is mandatory in response body (e.g. for GET, POST, etc.), and optional in input. The rationale here is that uri contents can undergo translation (due to API gateways, etc.) and so it is not reasonable to expect that a consumer can "know" what the href field will look like.
    There has been talk of allowing partial/relative uri in href (which would eliminate the variable part, that is generally in the area of the server, port, and base path), but most of our examples show full uri.
    If you look at recent conformance profile documents (in main API table or early access) you will see this.
    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.
    ------------------------------