Open APIs

Hi,

I am preparing TMF678 for a certification and I run into a quite a concern: a non specific (as no additional query parameters) GET /appliedCustomerBillingRate that is being tested.

Why I find it concerning:

• I can't see no bussines use case - it is hard for me to imagine a situation where a client would need and want to use it
• It will return millions and more of entities - pagination helps but for such huge amount only a little and still: why to use it anyway if we get unstructured list of charges as a result
• Allowing an open query  is treated by many as a security issue, for this API I feel there is additionally no benefit

Would it not be better if the API allowed to get charge data only with at least a context of a customer or an account ?
Is there no way to pass the test other than exposing this API ?
I feel it may concern more TMF APIs in general, but for this one the problem is very clear because of the nature of the charges

------------------------------
Pawel Polanski
Comarch S.A.
------------------------------

Hi Pawel
Thanks for raising this. It could apply to any of the customer-level entities (Customer itself, Product, Billing Account, Service, and many more).
The thing is, it's an implementation-specific decision on how to limit the scope of queries. I don't think that TMF, as a standard, can decide unilaterally that (for example) customer context is mandatory.
Additionally, there are (in principle) use cases where you might want to allow mass retrieval of data (presumably with cursor/keyset paging).
Hope this is reasonable

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