Re: Inconsistency in retrieval of service plans

John Feminella <jxf@...>

hi Roopali,
I think Benjamin meant
Ordering doesn't seem to be part of the contract of `inline-relations-depth`:
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)
t · @jxxf

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

The given link , , 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...

Join to automatically receive all group messages.