Open APIs

Hello

This is more general question than specific to any API.

Cloud native, multi-cloud and public cloud are becoming more and more prominent as part of ecosystem.

Making multiple calls over network in such situation is always going to have network contention.

When making a such intersystem calls, it will be performant to make payload to handle multiple requests than just making a single request. Especially in B2B scenario.

I tried to search the forums but have not come across any guidance for this scenario.

Also one more point to consider is that TMF specifications, the attribute names are taking more size than values. For single request this is fine however in case of multiple requests repeating the attribute names will make the payload unnecessarily large.

Another point could be having wrapper in between however it will result into proprietary layer.

It will be good to have some work to happen in this direction and guidance henceforth.

Thank you in advance.

In case this topic is not relevant please accept apologies.

Mandar

Hi Mandar,

Bulk resource creation is described in TMF 630 Part 1, Chapter "6.2. Creating Multiple Resources". Idea is to apply JSON Patch (RFC 6902) to the collection of the resources, hence nothing prevents us from building bulk resource update or deletion same way. Furthermore, TMF 630 Part 5 and 6 introduces JSON Patch extension, that overcomes the limitations of JSON Pointer notation (RFC 6901) and further contributes to the bulk operations with collections. 

However, worth noting that example given in TMF 630 Part 1, Chapter 6.2 doesn't look correct to me as it contradicts to RFC 6901 . it should be "/-" which would be "pointing to the new (nonexistent) member after the last array element" (c) RFC 6901, instead of "/" given in the example. Adding and Array Value example from RFC illustrates the point. Hence in my view, bulk resource creation should look as follows:

PATCH /api/troubleTicket
Content-type: application/json-patch+json
 
[
    {
        "op": "add",
        "path": "/-",
        "value": {
            "correlationId": "TT53482",
            "description": "Customer complaint over last invoice."
 
(... here follows the TroubleTicket value and the same structure for the rest of trouble tickets being created in a single transaction).

Bulk resource deletion 

PATCH /api/troubleTicket

Content-type: application/json-patch-query+json

[
    {
        "op": "remove",
        "path": "$[?(@.id=='this-is-the-trouble-ticket-id1')]"
    },
    {
        "op": "remove",
        "path": "$[?(@.id=='this-is-the-trouble-ticket-id2')]"
    },
    {
        "op": "remove",
        "path": "$[?(@.id=='this-is-the-trouble-ticket-idn')]"
    }
]

Bulk resource update along the same lines.  

As for the attribute values and perhaps some other performance concerns around bulk operations, HTTP/2 can be utilized to transfer TMF compliant payloads. Specifically HTTP/2 promotes compression of the payloads, hence long attribbute names repeated multiple times won't be an issue (at least not from the network point of view). 

Hope that helps. 

Hello

This is more general question than specific to any API.

Cloud native, multi-cloud and public cloud are becoming more and more prominent as part of ecosystem.

Making multiple calls over network in such situation is always going to have network contention.

When making a such intersystem calls, it will be performant to make payload to handle multiple requests than just making a single request. Especially in B2B scenario.

I tried to search the forums but have not come across any guidance for this scenario.

Also one more point to consider is that TMF specifications, the attribute names are taking more size than values. For single request this is fine however in case of multiple requests repeating the attribute names will make the payload unnecessarily large.

Another point could be having wrapper in between however it will result into proprietary layer.

It will be good to have some work to happen in this direction and guidance henceforth.

Thank you in advance.

In case this topic is not relevant please accept apologies.

Mandar