Open APIs

• you might want to design a task resource that takes an array of item IDs in its input and returns a correlated array of statuses in output.
• You need to consider whether you want "all or nothing" semantics, or rather you are prepared to accept partial failures.

• you'll probably prefer a job driven by a file or a stream of events
• the job will need to write statues to an output file or stream

• Managing referential integrity - if you delete an entity you may have "dangling pointers" (references) to a deleted entity so your software needs to be forgiving when trying to resolve such references
• Different statuses for failures to delete (e.g. entity not found, entity locked by another user, etc.)

• you might want to design a task resource that takes an array of item IDs in its input and returns a correlated array of statuses in output.
• You need to consider whether you want "all or nothing" semantics, or rather you are prepared to accept partial failures.

• you'll probably prefer a job driven by a file or a stream of events
• the job will need to write statues to an output file or stream

• Managing referential integrity - if you delete an entity you may have "dangling pointers" (references) to a deleted entity so your software needs to be forgiving when trying to resolve such references
• Different statuses for failures to delete (e.g. entity not found, entity locked by another user, etc.)

Hi @Jonathan Goldberg,

We have a similar doubt and i was thinking that it could be ok, for a small number of deletes in a single API call, to use the multiple adds pattern described in TMF630 guidelines. It would be ussing the PATCH on the managed entity colletion resource with json-patch body as follows:

PATCH /troubleTicket
​Content-type: application/json-patch+json

[
  {
    "op": "remove",
    "path": "/this-is-the-trouble-ticket-id1",
  },
  {
    "op": "remove",
    "path": "/this-is-the-trouble-ticket-id2",
  },
  {
    "op": "remove",
    "path": "/this-is-the-trouble-ticket-idn",
  },
]

It is not mentioned for deletes in the guidelines but for multiple adds, however I don't see a clear reason why "op"s should all be "add" and not replaces and removes. JSON Patch allows all the 3 operations to be used in other scenarios.

Regards,

Carlos Prados.

• you might want to design a task resource that takes an array of item IDs in its input and returns a correlated array of statuses in output.
• You need to consider whether you want "all or nothing" semantics, or rather you are prepared to accept partial failures.

• you'll probably prefer a job driven by a file or a stream of events
• the job will need to write statues to an output file or stream

• Managing referential integrity - if you delete an entity you may have "dangling pointers" (references) to a deleted entity so your software needs to be forgiving when trying to resolve such references
• Different statuses for failures to delete (e.g. entity not found, entity locked by another user, etc.)

Carlos - sorry for the delay in relating to this post.

It seems to me that this will be good for PATCHing lists of sub-entities. But it won't work for deletes of multiple top-level (managed) entities.

Hi @Jonathan Goldberg,

We have a similar doubt and i was thinking that it could be ok, for a small number of deletes in a single API call, to use the multiple adds pattern described in TMF630 guidelines. It would be ussing the PATCH on the managed entity colletion resource with json-patch body as follows:

PATCH /troubleTicket
​Content-type: application/json-patch+json

[
  {
    "op": "remove",
    "path": "/this-is-the-trouble-ticket-id1",
  },
  {
    "op": "remove",
    "path": "/this-is-the-trouble-ticket-id2",
  },
  {
    "op": "remove",
    "path": "/this-is-the-trouble-ticket-idn",
  },
]

It is not mentioned for deletes in the guidelines but for multiple adds, however I don't see a clear reason why "op"s should all be "add" and not replaces and removes. JSON Patch allows all the 3 operations to be used in other scenarios.

Regards,

Carlos Prados.

• you might want to design a task resource that takes an array of item IDs in its input and returns a correlated array of statuses in output.
• You need to consider whether you want "all or nothing" semantics, or rather you are prepared to accept partial failures.

• you'll probably prefer a job driven by a file or a stream of events
• the job will need to write statues to an output file or stream

• Managing referential integrity - if you delete an entity you may have "dangling pointers" (references) to a deleted entity so your software needs to be forgiving when trying to resolve such references
• Different statuses for failures to delete (e.g. entity not found, entity locked by another user, etc.)

Hi Jonathan,

This pattern is being proposed in TMF630 part 1, chapter "6.2. Creating Multiple Resources", ussing it like this:

PATCH /api/troubleTicket
Content-type: application/json-patch+json

[
{
  "op": "add",
  "path": "/",
  "value": {
    "id": "42",
    "href": " /troubleTicketManagement/troubleTicket/42",
    "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).

Do you know why this should be ok for bulk adding and not for bulk deleting or replacing?

For manegeable amounts of data in payloads, I think it could be better than implementing a custom task resource.

Regards,
Carlos Prados.

Carlos - sorry for the delay in relating to this post.

It seems to me that this will be good for PATCHing lists of sub-entities. But it won't work for deletes of multiple top-level (managed) entities.

Hi @Jonathan Goldberg,

We have a similar doubt and i was thinking that it could be ok, for a small number of deletes in a single API call, to use the multiple adds pattern described in TMF630 guidelines. It would be ussing the PATCH on the managed entity colletion resource with json-patch body as follows:

PATCH /troubleTicket
​Content-type: application/json-patch+json

[
  {
    "op": "remove",
    "path": "/this-is-the-trouble-ticket-id1",
  },
  {
    "op": "remove",
    "path": "/this-is-the-trouble-ticket-id2",
  },
  {
    "op": "remove",
    "path": "/this-is-the-trouble-ticket-idn",
  },
]

It is not mentioned for deletes in the guidelines but for multiple adds, however I don't see a clear reason why "op"s should all be "add" and not replaces and removes. JSON Patch allows all the 3 operations to be used in other scenarios.

Regards,

Carlos Prados.

• you might want to design a task resource that takes an array of item IDs in its input and returns a correlated array of statuses in output.
• You need to consider whether you want "all or nothing" semantics, or rather you are prepared to accept partial failures.

• you'll probably prefer a job driven by a file or a stream of events
• the job will need to write statues to an output file or stream

• Managing referential integrity - if you delete an entity you may have "dangling pointers" (references) to a deleted entity so your software needs to be forgiving when trying to resolve such references
• Different statuses for failures to delete (e.g. entity not found, entity locked by another user, etc.)

We actually had an internal email exchange about this in the Open API team. @Florin Tene - the focal for the guidelines - may be able to give more details about the support at collection level.

------------------------------
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.

Original Message:
Sent: Feb 27, 2023 06:01
From: Carlos Prados
Subject: Bulk delete operation

Hi Jonathan,

This pattern is being proposed in TMF630 part 1, chapter "6.2. Creating Multiple Resources", ussing it like this:

PATCH /api/troubleTicket
Content-type: application/json-patch+json

[
{
  "op": "add",
  "path": "/",
  "value": {
    "id": "42",
    "href": " /troubleTicketManagement/troubleTicket/42",
    "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).

Do you know why this should be ok for bulk adding and not for bulk deleting or replacing?

For manegeable amounts of data in payloads, I think it could be better than implementing a custom task resource.

Regards,
Carlos Prados.

------------------------------
Carlos Prados
Vodafone Group

Original Message:
Sent: Feb 20, 2023 10:25
From: Jonathan Goldberg
Subject: Bulk delete operation

Carlos - sorry for the delay in relating to this post.

It seems to me that this will be good for PATCHing lists of sub-entities. But it won't work for deletes of multiple top-level (managed) entities.

------------------------------
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.

Original Message:
Sent: Feb 03, 2023 04:50
From: Carlos Prados
Subject: Bulk delete operation

Hi @Jonathan Goldberg,

We have a similar doubt and i was thinking that it could be ok, for a small number of deletes in a single API call, to use the multiple adds pattern described in TMF630 guidelines. It would be ussing the PATCH on the managed entity colletion resource with json-patch body as follows:

PATCH /troubleTicket
​Content-type: application/json-patch+json

[
  {
    "op": "remove",
    "path": "/this-is-the-trouble-ticket-id1",
  },
  {
    "op": "remove",
    "path": "/this-is-the-trouble-ticket-id2",
  },
  {
    "op": "remove",
    "path": "/this-is-the-trouble-ticket-idn",
  },
]

It is not mentioned for deletes in the guidelines but for multiple adds, however I don't see a clear reason why "op"s should all be "add" and not replaces and removes. JSON Patch allows all the 3 operations to be used in other scenarios.

Regards,

Carlos Prados.

------------------------------
Carlos Prados
Vodafone Group

Original Message:
Sent: Jan 17, 2023 01:26
From: kartik maringanti
Subject: Bulk delete operation

Thank you @Jonathan Goldberg​

------------------------------
Kartik N Maringanti
Verizon

Original Message:
Sent: Jan 15, 2023 02:37
From: Jonathan Goldberg
Subject: Bulk delete operation

Hi Kartik

To some extent it depends on the size of the bulk.
For "small" numbers (e.g. up to 1000):

• you might want to design a task resource that takes an array of item IDs in its input and returns a correlated array of statuses in output.
• You need to consider whether you want "all or nothing" semantics, or rather you are prepared to accept partial failures.

For "large" numbers (e.g. greater than 1000):

• you'll probably prefer a job driven by a file or a stream of events
• the job will need to write statues to an output file or stream

In either case, consider the following:

• Managing referential integrity - if you delete an entity you may have "dangling pointers" (references) to a deleted entity so your software needs to be forgiving when trying to resolve such references
• Different statuses for failures to delete (e.g. entity not found, entity locked by another user, etc.)

------------------------------
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.

Original Message:
Sent: Jan 13, 2023 01:19
From: kartik maringanti
Subject: Bulk delete operation

Hello Team,

I do understand that it is not recommended approach to go with the bulk delete option, as the control to delete should be done from the client in an iteration for each resource using DELETE /resource/{id}. But if given a requirement to bulk delete, what possible design guidelines can be proposed.

------------------------------
Kartik N Maringanti
Verizon
------------------------------

That's fine. I'm interested in the conclusions of that email exchange, if possibe.

By the way I think the example in chapter 6.2 of the guide, part 1, is wrong, cause they are passing the "id" when they are adding a record.

I think the object should be a TroubleTicket_Create, without the "id" and the "href", cause it doesn't exists in the server jet, and cannot have an "id".

------------------------------
Carlos Prados
Vodafone Group

Original Message:
Sent: Feb 28, 2023 16:03
From: Jonathan Goldberg
Subject: Bulk delete operation

We actually had an internal email exchange about this in the Open API team. @Florin Tene - the focal for the guidelines - may be able to give more details about the support at collection level.

------------------------------
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.

Original Message:
Sent: Feb 27, 2023 06:01
From: Carlos Prados
Subject: Bulk delete operation

Hi Jonathan,

This pattern is being proposed in TMF630 part 1, chapter "6.2. Creating Multiple Resources", ussing it like this:

PATCH /api/troubleTicket
Content-type: application/json-patch+json

[
{
  "op": "add",
  "path": "/",
  "value": {
    "id": "42",
    "href": " /troubleTicketManagement/troubleTicket/42",
    "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).

Do you know why this should be ok for bulk adding and not for bulk deleting or replacing?

For manegeable amounts of data in payloads, I think it could be better than implementing a custom task resource.

Regards,
Carlos Prados.

------------------------------
Carlos Prados
Vodafone Group

Original Message:
Sent: Feb 20, 2023 10:25
From: Jonathan Goldberg
Subject: Bulk delete operation

Carlos - sorry for the delay in relating to this post.

It seems to me that this will be good for PATCHing lists of sub-entities. But it won't work for deletes of multiple top-level (managed) entities.

------------------------------
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.

Original Message:
Sent: Feb 03, 2023 04:50
From: Carlos Prados
Subject: Bulk delete operation

Hi @Jonathan Goldberg,

We have a similar doubt and i was thinking that it could be ok, for a small number of deletes in a single API call, to use the multiple adds pattern described in TMF630 guidelines. It would be ussing the PATCH on the managed entity colletion resource with json-patch body as follows:

PATCH /troubleTicket
​Content-type: application/json-patch+json

[
  {
    "op": "remove",
    "path": "/this-is-the-trouble-ticket-id1",
  },
  {
    "op": "remove",
    "path": "/this-is-the-trouble-ticket-id2",
  },
  {
    "op": "remove",
    "path": "/this-is-the-trouble-ticket-idn",
  },
]

It is not mentioned for deletes in the guidelines but for multiple adds, however I don't see a clear reason why "op"s should all be "add" and not replaces and removes. JSON Patch allows all the 3 operations to be used in other scenarios.

Regards,

Carlos Prados.

------------------------------
Carlos Prados
Vodafone Group

Original Message:
Sent: Jan 17, 2023 01:26
From: kartik maringanti
Subject: Bulk delete operation

Thank you @Jonathan Goldberg​

------------------------------
Kartik N Maringanti
Verizon

Original Message:
Sent: Jan 15, 2023 02:37
From: Jonathan Goldberg
Subject: Bulk delete operation

Hi Kartik

To some extent it depends on the size of the bulk.
For "small" numbers (e.g. up to 1000):

• you might want to design a task resource that takes an array of item IDs in its input and returns a correlated array of statuses in output.
• You need to consider whether you want "all or nothing" semantics, or rather you are prepared to accept partial failures.

For "large" numbers (e.g. greater than 1000):

• you'll probably prefer a job driven by a file or a stream of events
• the job will need to write statues to an output file or stream

In either case, consider the following:

• Managing referential integrity - if you delete an entity you may have "dangling pointers" (references) to a deleted entity so your software needs to be forgiving when trying to resolve such references
• Different statuses for failures to delete (e.g. entity not found, entity locked by another user, etc.)

------------------------------
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.

Original Message:
Sent: Jan 13, 2023 01:19
From: kartik maringanti
Subject: Bulk delete operation

Hello Team,

I do understand that it is not recommended approach to go with the bulk delete option, as the control to delete should be done from the client in an iteration for each resource using DELETE /resource/{id}. But if given a requirement to bulk delete, what possible design guidelines can be proposed.

------------------------------
Kartik N Maringanti
Verizon
------------------------------

Hi @Jonathan Goldberg,

We have a similar doubt and i was thinking that it could be ok, for a small number of deletes in a single API call, to use the multiple adds pattern described in TMF630 guidelines. It would be ussing the PATCH on the managed entity colletion resource with json-patch body as follows:

PATCH /troubleTicket
​Content-type: application/json-patch+json

[
  {
    "op": "remove",
    "path": "/this-is-the-trouble-ticket-id1",
  },
  {
    "op": "remove",
    "path": "/this-is-the-trouble-ticket-id2",
  },
  {
    "op": "remove",
    "path": "/this-is-the-trouble-ticket-idn",
  },
]

It is not mentioned for deletes in the guidelines but for multiple adds, however I don't see a clear reason why "op"s should all be "add" and not replaces and removes. JSON Patch allows all the 3 operations to be used in other scenarios.

Regards,

Carlos Prados.

• you might want to design a task resource that takes an array of item IDs in its input and returns a correlated array of statuses in output.
• You need to consider whether you want "all or nothing" semantics, or rather you are prepared to accept partial failures.

• you'll probably prefer a job driven by a file or a stream of events
• the job will need to write statues to an output file or stream

• Managing referential integrity - if you delete an entity you may have "dangling pointers" (references) to a deleted entity so your software needs to be forgiving when trying to resolve such references
• Different statuses for failures to delete (e.g. entity not found, entity locked by another user, etc.)