Inconsistency in retrieval of service plans


John Feminella <jxf@...>
 

hi Roopali,
I think Benjamin meant https://apidocs.cloudfoundry.org.
Ordering doesn't seem to be part of the contract of `inline-relations-depth`:
https://apidocs.cloudfoundry.org/258/services/list_all_service_plans_for_the_service.html
So the ordering is likely to be arbitrary if you use that parameter; since it's
arbitrary, you probably shouldn't depend on it.From the documentation,
`inline-relations-depth` is deprecated, so I also wouldn't depend on it for that
reason either.
Not sure if this works for you, but maybe you can get what you want by using the
`?q=…` query to get the correct ordering, then including whatever data you'd
like from the arbitrarily-ordered `inline-relations-depth` query and merging the
two results.
best,~ jf--John Feminella
Advisory Platform Architect
✉ ·jxf(a)pivotal.io
t · @jxxf

On Wed, May 10, 2017 5:47 AM, Roopali Sharma roopali1193(a)gmail.com wrote:
Hello,




The given link , http://api.cloudfoundry.org/ , does not give any details as to
the implementation differences of the APIs wherein the discrepancy lies,




For my investigations, I deployed a sample broker with ten sample plans , with
the first call which is " /v2/service_plans?q=<service_guid> " the plan order of
broker is respected at all times but the second call does some sort using
plan_ids, plan name and plan types(free or paid, public or private) and responds
with a differently ordered list . Could you redirect me to some link where in
this difference is clarified...


Roopali Sharma <roopali1193@...>
 

Hello,

The given link , http://api.cloudfoundry.org/ , does not give any details as to the implementation differences of the APIs wherein the discrepancy lies,

For my investigations, I deployed a sample broker with ten sample plans , with the first call which is " /v2/service_plans?q=<service_guid> " the plan order of broker is respected at all times but the second call does some sort using plan_ids, plan name and plan types(free or paid, public or private) and responds with a differently ordered list . Could you redirect me to some link where in this difference is clarified...


Benjamin Gandon
 

Did you look at the doc on api.cloudfoundry.org about any ordering contract for those API calls?

Le 5 mai 2017 à 12:16, Roopali Sharma <roopali1193(a)gmail.com> a écrit :

Hello All,



While listing service plans for any given service , if we use /v2/service_plans?q=<service_guid> , the plans appear in the same order as defined in the service catalog. However, call to /v2/services/<service_guid>?inline-relations-depth=1 returns the service plans in some random ordering which does not respect the order of catalog. The ordering however does not change with every call and also does not seem to take into account unique plan_id or the plan_name itself. Hence , it is unclear as to what sorting paradigm is in use.



Can someone comment if this is a bug with controller API or if not, some clarity regarding the ranking order.



With regards,

Roopali Sharma


Roopali Sharma <roopali1193@...>
 

Hello All,



While listing service plans for any given service , if we use
/v2/service_plans?q=<service_guid> , the plans appear in the same order as
defined in the service catalog. However, call to
/v2/services/<service_guid>?inline-relations-depth=1 returns the service
plans in some random ordering which does not respect the order of catalog.
The ordering however does not change with every call and also does not seem
to take into account unique plan_id or the plan_name itself. Hence , it is
unclear as to what sorting paradigm is in use.



Can someone comment if this is a bug with controller API or if not, some
clarity regarding the ranking order.



With regards,

Roopali Sharma