Open APIs

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

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.

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

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:

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

Regards

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.