Date
1 - 4 of 4
Inconsistency in retrieval of service plans
|
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 |
|
|
|
Did you look at the doc on api.cloudfoundry.org about any ordering contract for those API calls?
toggle quoted message
Show quoted text
Le 5 mai 2017 à 12:16, Roopali Sharma <roopali1193(a)gmail.com> a écrit : |
|
|
|
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... |
|
|
|
John Feminella <jxf@...>
hi Roopali,
toggle quoted message
Show quoted text
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... |
|
|