Open APIs

 View Only
  • 1.  TMF679: Using reduced swaggr

    Posted May 16, 2022 14:34

    I'm currently designing application to use TMF679 API for product offering qualification. As checked in the API documentation and swagger, I can find that we will not be using all operations and attributes. Hence, is it ok to create our own reduced version of swagger including only those details which are needed for our functionality?


    Paras Agrawal

  • 2.  RE: TMF679: Using reduced swaggr

    TM Forum Member
    Posted May 17, 2022 01:55
    Hi Paras
    You can do whatever you like :) , providing that you are not seeking to certify your API implementation for conformance with the Open API standard.
    However, if you want certification, you should examine the API's CTK to see what the minimum mandatory implementation is.

    And of course you should make it clear to your API consumers that you are not providing a complete implementation of the API as documented in TMF publications.

    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.

  • 3.  RE: TMF679: Using reduced swaggr

    TM Forum Member
    Posted May 18, 2022 01:17
    @Paras Agrawal,

    IMHO you should create your own OAS ("swagger") and provide it at runtime. That specification should contain no lies, so do not advertise operations you do not support and it's unnecessary to ​include attributes you will ignore and never return. Very few if any actors will actually consume an OAS in runtime. The TMF CTKs do not. If anyone is consuming your OAS the intention would be to understand your implementation specifically. At SigScale we provide OAS 3.0 to document SigScale APIs, which happen to be conformant with TM Forum Open APIs (we use 3.0 because it has better documentation features). While AFAIK these are only being consumed at design time, by providing them from the production platforms they are kept up to date with the implementation.

    Vance Shipley