list related resources

[mikemrm]

Expose a method to list resources related to a given resource.

Fetching /relationships/from/:resource_id will return relationships directly assigned to this resource.

# GET /relationships/from/tnntten-abc12-3
{
  "data": [
    {
      "relation": "parent",
      "subject_id": "tnntten-abc12"
    }
  ]
}

Fetching /relationships/to/:resource_id will return relationships for resources which have a relation to this resource.

# GET /relationships/to/tnntten-abc12-3
{
  "data": [
    {
      "resource_id": "loadbal-abc123",
      "relation": "owner"
    },
    {
      "resource_id": "loadbal-abc456",
      "relation": "owner"
    }
  ]
}

[nicolerenee]

I think I would like to see a way to get the things in a specific relationship.

So GET /resources/tnntten-abc12-3/relationships would return a list of the relationships available, so owner and whatever else. Then /resources/tnntten-abc12-3/relationships/owners would return the owners. Because when there are multiple types of relationships I'm likely going to want to get the specific one.

I'm not 100% sure when we would want to use this API though, so what are you thinking there?

[mikemrm]

That makes sense. With the limitations of spicedb's query requiring a Resource Type, we would have to loop through all possible resource types and fetch each individually and then combine the outputs. But this is something we're already doing for role deletions as well.

[jnschaeffer]

@nicolerenee Is your thinking here that we provide a URL path component/query parameter describing the relation itself? For example, if we have a schema that looks like so:

definition foo/tenant {}

definition foo/instance {
  relation owner: foo/tenant
  relation other_tenant: foo/tenant
}

We would then have a URL like /resources/instanc-abc123/relationships/other_tenant?

[nicolerenee]

@jnschaeffer yeah, that's exactly what I'm thinking. Usually if I'm trying to get the relationships of something I would imagine I'm trying to get a specific one. But I guess the question is what are we wanting this URL for?

[jnschaeffer]

Looks good at a glance - one question though.

[jnschaeffer]

Are we keeping the existing API endpoint so as to not break compatibility?

[mikemrm]

Yeah, no real reason other than that.