Open APIs

 View Only

  • 1.  TMF641 v5 - JSON Path as an Alternative to JSON Pointer

    TM Forum Member
    Posted 17 days ago

    Hello everyone,

    In TMF641 v5, the specification introduces JSONPatch sub-resource and prescribes JSON Pointer as the method for identifying parts of a JSON document (referenced on pages 26 and 68).

    However, this seems to contradict the recommendation in TMF630 Part 6, which promotes JSON Path as a de facto standard, offering significantly more flexibility then JSON Pointer. For example, JSON Path supports conditional logic and more advanced querying capabilities.

    Given this, would it be worth considering providing alternatives in TMF641 v5 for implementations to support either JSON Pointer or JSON Path, depending on the use case?

    Kindest regards



    ------------------------------
    Taras Pushyk
    GlobalLogic
    ------------------------------


  • 2.  RE: TMF641 v5 - JSON Path as an Alternative to JSON Pointer

    TM Forum Member
    Posted 16 days ago

    Hi Taras,

    I think that using the JSON Path syntax does not violate the TMF641 specification. Because this use explicitly described in the TMF630 REST API Design Guidelines Part 5, the section "JSON Patch with "filter" selector (JSON Path)".

    With the addition of the Design Guidelines 6 - JSON Patch, the JSON Patch Query has been updated to
support the addition selector called "filter" allowing the enhancement of the query with the JSON Path
syntax.



    ------------------------------
    Yurii Yushchak
    System Manager
    Ericsson Inc.
    ------------------------------

    Original Message


  • 3.  RE: TMF641 v5 - JSON Path as an Alternative to JSON Pointer

    TM Forum Member
    Posted 15 days ago

    Hi Taras,
    I think it also helps to understand that the specification that the JsonPatch "path" should be defined as a JSON pointer does not come directly from the TM forum, but ratherfrom the IETF RFC6902 specification. See https://datatracker.ietf.org/doc/html/rfc6902 

    And as Yurrii mentioned, TM Forum identified this lack of features and this is why the came up with the JSON Patch Query extension.

    Regards,
    Jan



    Regards,
    Jan



    ------------------------------
    Jan Lemmermann
    OSS Lead Architect
    EWE TEL GmbH
    ------------------------------

    Original Message


  • 4.  RE: TMF641 v5 - JSON Path as an Alternative to JSON Pointer

    TM Forum Member
    Posted 15 days ago

    Hi Yurii, Jan,

    Thank you for your comments. I understand that, based on TMF630 guidelines, TMF641 implementations might opt to use JSON Path as an extension to the TMF641 v5 specifications. However, this would require them to support both JSON Pointer and JSONPath. This is essentially what TMF630 Part 5 suggests:

    Operations

    Operation in a JSON Patch Query document are handled in the same way as for a JSON Patch document but the query parameter in the "path" member is used to identify the element within an array that is impacted by the operation, the one that matches all the criteria included in the query expression.

    When the query is not required because the array index can be used, this format is handled in the same way as JSON Patch [RFC6902]. 

    So, the question is whether the upcoming TMF641 specification could incorporate greater flexibility in this regard.

    Regards



    ------------------------------
    Taras Pushyk
    GlobalLogic
    ------------------------------

    Original Message


  • 5.  RE: TMF641 v5 - JSON Path as an Alternative to JSON Pointer

    TM Forum Member
    Posted 14 days ago

    In TMF686 Topology Graph API we did have to use json path with w3C extensions for Functions so that we could describe graph database style graph traversal requests.  So these didn't raise an issue about whether they violated the TMF630 guidelines; but of course you have to have the requisite functionality implemented behind the API. 



    ------------------------------
    Dave Milham
    TM Forum, Chief Architect
    ------------------------------

    Original Message