Includes for service instances

[krismarc]

Is there any reason why there are no includes for service instances?
This would save tons of calls. Eg python client doesn't seem to support fields cloudfoundry-community/cf-python-client#247

If orgs, spaces or even apps would be possible to be included my small benchmark mentioned here cloudfoundry-community/cf-python-client#218 (comment) would also apply for service instances.

[johha]

Service instances are not directly mapped to apps for this v3/service-credential-bindings can be used. I even overs includes for apps and service instances.

What is the use case for having includes in service instances?

[krismarc]

@johha, Reduction in the number of calls against API. Having parents objects (org and space) out of single call would be beneficial in this case. You do so for apps, I don't understand why only fields are available for service instances. I'd be mainly interested in space.organization, space. Apps would be something extra and can be handled as you have stated.

https://v3-apidocs.cloudfoundry.org/version/3.198.0/index.html#include

even service plans offers includes, so missing service instances and reference to their space.organization and space looks to me like an overlook.

write some more complex reporting for service instances within bigger cf deployment and you will quickly realize where my problem comes from

[johha]

There might be a (historic) reason like to large json output etc. why include was not considered for service instances.
@Gerg @sethboyles Do you remember any details about include vs fields parameters for service instances?

[sethboyles]

I don't know the history, but from looking at what we have provided as includes options in the past are typically belongs_to relationships--so you know for every resource, you will only get (at most) one extra included resource per core resource.

The relationship between apps and service_instances, which is many-to-many, would result in an unpredictable response size. Perhaps that's why?

[krismarc]

@sethboyles Ok, in terms of apps this makes sense. You might bind one service instance to many apps. What about space and space.organization?

Developers may choose to use the include feature to reduce the number of API calls. The include query param can be used with a single resource or a list of resources.
https://v3-apidocs.cloudfoundry.org/version/3.198.0/index.html#include

Some relationships relate a resource to exactly one other resource. For example an app can belong to only one space.
https://v3-apidocs.cloudfoundry.org/version/3.198.0/index.html#to-one-relationships

I believe both of above statements meet criteria for service instances to have inclusion of space and space.organization. Service instance might exist only in one space and org. Service sharing is rather another abstraction, no?

so my main question is, why do we provide inclusion of space and space.organization for apps endpoint and there's no equal possibility for service instances?

[sethboyles]

Adding space and space.organization seems reasonable to me.

[krismarc]

Adding space and space.organization seems reasonable to me.

Thank you.

I just checked API changes. Inclusions were shaped between 3.71 and 3.95. It seems to me like an overlook.