Open APIs

 View Only
  • 1.  TMF678 - appliedCustomerBillingRate

    TM Forum Member
    Posted Nov 10, 2022 14:50
    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.
    ------------------------------


  • 2.  RE: TMF678 - appliedCustomerBillingRate

    TM Forum Member
    Posted Nov 13, 2022 02:39
    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.
    ------------------------------