Open APIs

Expand all | Collapse all

Recommendation API TMF680

  • 1.  Recommendation API TMF680

    TM Forum Member
    Posted 24 days ago
    Hello,

    I can see in the specification for Recommendation API, only get api is mentioned as below 

    GET /recommendation?fields=...&{filtering}

    The specification does not mention any specific fields to be used for filtering although there are few examples. Just wanted to confirm that it is allowed to freely pass any filters we expect.

    Also it does not mention any POST request specifications, so what creates the HREF - "href":"http://serverlocation:port/recommendation/v1/recommendation/1001", in the response?

    Thanks for your help



    ------------------------------
    Sachin Kale
    ------------------------------


  • 2.  RE: Recommendation API TMF680

    TM Forum Member
    Posted 23 days ago
    Sachin, you raise some interesting points, thanks.

    The Recommendation API is not the only API that has no POST - take for example Customer Bill Management (TMF678). That API assumes that bills are created by some automatic process and so can be retrieved (GET) but not created (no POST)

    There are of course many ways to generate recommendation, but conceptually we can imagine some offline process crunching the data, creating recommendations, and perhaps sending them proactively to consumers. So the recommendations (like the bills) already exist, just "waiting" to be discovered.

    Regarding filters, consult the guidelines document for more details at https://projects.tmforum.org/wiki/display/PUB/TMF630+API+Design+Guidelines+3.0+R17.5.1 (part 1)

    Finally,​ the lead for this API is Helen (haohongxia) from Huawei, she may be able to provide you with additional information.

    Hope it helps.​​

    ------------------------------
    Jonathan Goldberg
    Amdocs Management Limited
    ------------------------------



  • 3.  RE: Recommendation API TMF680

    TM Forum Member
    Posted 13 days ago
    Hi Sachin, Jonathan,

    Thanks for insights. I encountered the same issue and share the same concern as Sachin. Does that assumption not break microservice principles i.e. multiple access paths for the persistence back-end of this API?

    Regards,
    Amir Hassan.

    ------------------------------
    Amir Hassan
    Deutsche Telekom AG
    ------------------------------



  • 4.  RE: Recommendation API TMF680

    TM Forum Member
    Posted 13 days ago
    Hi
    This is my personal opinion only, of course. But I think we should not be dogmatic about this. For real-time performance in charging and billing it probably doesn't make sense that each network event will cause a REST API call - the latency is probably too high. Provided that the creation logic is isolated to a single component, it seems (to me) reasonable that the component could expose a REST API allowing external consumers to create an entity, but also have other low-latency mechanisms for creation.

    ------------------------------
    Jonathan Goldberg
    Amdocs Management Limited
    ------------------------------