Open APIs

Hi David,

What I interpret in the document is that there should always have a category in the middle. I mean, a specification is made available to a category through a candidate. In turn, the category can be related to several catalogs. So, the relationship between the candidate and the catalog is established through the category.

Hope it helps.

Regards,

To be honest, I had suggested in the past that we should simply the service (and resource) model by removing the Candidate entity. However my suggestion was rejected, so the ServiceCandidate and ResourceCandidate entities remain. I think that @Koen Peeters has posted in the community explaining what use cases might justify the existence of the Candidate entities.

Hi David,

What I interpret in the document is that there should always have a category in the middle. I mean, a specification is made available to a category through a candidate. In turn, the category can be related to several catalogs. So, the relationship between the candidate and the catalog is established through the category.

Hope it helps.

Regards,

@Koen Peeters could you drop a link to the thread please?

@Jonathan Goldberg  thanks for your reply.

I guess i wasnt as such questioning the existence of the service candidate it was more that i didnt see what endpoint you can use in the TMF API to bring back a list of service candidates associated with a service catalog. Is the answer that you must...

1. request the catalog to get a list of categories
2. request the categories based on the list received from 1
3. request for the candidates based on the list received from 2
4. request for the specifications based on the list received from 3

So 4 different endpoint calls to get to what i guess is the 'actual' items within the catalog?

Doesnt this relationship of Specification --> Candidate --> Category --> Catalog have its drawbacks? What if i don't want all of the candidates from a specific category within a catalog? Or is there a different way to achieve?

thanks

Dave

To be honest, I had suggested in the past that we should simply the service (and resource) model by removing the Candidate entity. However my suggestion was rejected, so the ServiceCandidate and ResourceCandidate entities remain. I think that @Koen Peeters has posted in the community explaining what use cases might justify the existence of the Candidate entities.

Hi David,

What I interpret in the document is that there should always have a category in the middle. I mean, a specification is made available to a category through a candidate. In turn, the category can be related to several catalogs. So, the relationship between the candidate and the catalog is established through the category.

Hope it helps.

Regards,

Hi David
It's important to be aware that the relationship models in TMF Open API are generally uni-directional. So in the service catalog area this implies that direct retrieval works in the way you describe. But this doesn't stop reverse retrieval by query, so you could do a direct GET of all the service candidates and use Category, or even Catalog, as a filter criterion.

@Koen Peeters could you drop a link to the thread please?

@Jonathan Goldberg  thanks for your reply.

I guess i wasnt as such questioning the existence of the service candidate it was more that i didnt see what endpoint you can use in the TMF API to bring back a list of service candidates associated with a service catalog. Is the answer that you must...

1. request the catalog to get a list of categories
2. request the categories based on the list received from 1
3. request for the candidates based on the list received from 2
4. request for the specifications based on the list received from 3

So 4 different endpoint calls to get to what i guess is the 'actual' items within the catalog?

Doesnt this relationship of Specification --> Candidate --> Category --> Catalog have its drawbacks? What if i don't want all of the candidates from a specific category within a catalog? Or is there a different way to achieve?

thanks

Dave

To be honest, I had suggested in the past that we should simply the service (and resource) model by removing the Candidate entity. However my suggestion was rejected, so the ServiceCandidate and ResourceCandidate entities remain. I think that @Koen Peeters has posted in the community explaining what use cases might justify the existence of the Candidate entities.

Hi David,

What I interpret in the document is that there should always have a category in the middle. I mean, a specification is made available to a category through a candidate. In turn, the category can be related to several catalogs. So, the relationship between the candidate and the catalog is established through the category.

Hope it helps.

Regards,

@Koen Peeters could you drop a link to the thread please?

@Jonathan Goldberg  thanks for your reply.

I guess i wasnt as such questioning the existence of the service candidate it was more that i didnt see what endpoint you can use in the TMF API to bring back a list of service candidates associated with a service catalog. Is the answer that you must...

1. request the catalog to get a list of categories
2. request the categories based on the list received from 1
3. request for the candidates based on the list received from 2
4. request for the specifications based on the list received from 3

So 4 different endpoint calls to get to what i guess is the 'actual' items within the catalog?

Doesnt this relationship of Specification --> Candidate --> Category --> Catalog have its drawbacks? What if i don't want all of the candidates from a specific category within a catalog? Or is there a different way to achieve?

thanks

Dave

------------------------------
David Whitfield
TalkTalk Group
------------------------------


Original Message:
Sent: May 21, 2023 08:47
From: Jonathan Goldberg
Subject: Service Catalog --> Service Candidate Link

To be honest, I had suggested in the past that we should simply the service (and resource) model by removing the Candidate entity. However my suggestion was rejected, so the ServiceCandidate and ResourceCandidate entities remain. I think that @Koen Peeters has posted in the community explaining what use cases might justify the existence of the Candidate entities.

------------------------------
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: May 18, 2023 03:48
From: Abel Ruiz Huerta
Subject: Service Catalog --> Service Candidate Link

Hi David,

What I interpret in the document is that there should always have a category in the middle. I mean, a specification is made available to a category through a candidate. In turn, the category can be related to several catalogs. So, the relationship between the candidate and the catalog is established through the category.

Hope it helps.

Regards,

------------------------------
Abel Ruiz Huerta
alvatross by SATEC