Open APIs

Hi, 

How to deal with a large collections inside a model e.g. what should be shown when customer (TMF_629) has a lot of agreements (A list of agreement references (AgreementRef [*])). Should we show the full list list or a part of it? 

I understand that this could be a theoretical problem, but do you have any recommendations?

Kind regards

------------------------------
Adam Augustyn
Comarch S.A.
------------------------------

Hi Adam

What should be shown? What your business product owner wants you to show.

I think that we should refine the question to the behavior of the backend API - how can we restrict the amount of data returned for long lists of sub-entities.
If your implementation supports it, you could use JSON Path notation to define filter criteria for sub-lists, see the design guidelines TMF630 Chapter 6.

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

Hi Jonathan, 

Thank you for your answer. If I understand correctly in TMF API there is no limit of sub-entities and if my business product owner decided that e.g. some business customer could have thousands of accounts, our REST API should return that. And to filter the data we can use JSON Path expressions which are mentioned in the design guideline?

Am I right?

Kind regards

------------------------------
Adam Augustyn
Comarch S.A.
------------------------------

Original Message:
Sent: Mar 21, 2022 10:48
From: Jonathan Goldberg
Subject: Large amount of data inside a collection

Hi Adam

What should be shown? What your business product owner wants you to show.

I think that we should refine the question to the behavior of the backend API - how can we restrict the amount of data returned for long lists of sub-entities.
If your implementation supports it, you could use JSON Path notation to define filter criteria for sub-lists, see the design guidelines TMF630 Chapter 6.

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

I think so, yes. Perhaps @Florin Tene, who authored the JSON Path guideline chapter, wants to add something to this discussion?​

------------------------------
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: Mar 23, 2022 05:57
From: Adam Augustyn
Subject: Large amount of data inside a collection

Hi Jonathan, 

Thank you for your answer. If I understand correctly in TMF API there is no limit of sub-entities and if my business product owner decided that e.g. some business customer could have thousands of accounts, our REST API should return that. And to filter the data we can use JSON Path expressions which are mentioned in the design guideline?

Am I right?

Kind regards

------------------------------
Adam Augustyn
Comarch S.A.
------------------------------


Original Message:
Sent: Mar 21, 2022 10:48
From: Jonathan Goldberg
Subject: Large amount of data inside a collection

Hi Adam

What should be shown? What your business product owner wants you to show.

I think that we should refine the question to the behavior of the backend API - how can we restrict the amount of data returned for long lists of sub-entities.
If your implementation supports it, you could use JSON Path notation to define filter criteria for sub-lists, see the design guidelines TMF630 Chapter 6.

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.