Closed tkellen closed 9 years ago
Currently, the application operates without any organization data whatsoever. The best way to handle this would be to get projects in the initial phase request. As of this moment, the application issues a request for /phases?include=projects
, but this would require requesting additional information about the (already nested) projects.
Alternatively, I could make yet another request with every page navigation, something like:
/organizations/{{ visibleProjects.map(function(project) { return project.organization_id; }).join(',') }}
It may be obvious, but I much prefer the former approach. That said, I don't know how difficult it would be to extend the API in that way, and I don't know the importance of this feature. I'll defer to you on how we should proceed.
Requesting nested relations is definitely something the API needs to support. I'll see if I can get it in by EOD. I actually have it working now but the spec has an interesting requirement I'm trying to clarify with @dgeb now:
Note: a request for comments.author should not automatically also include comments in the response (although comments will obviously need to be queried in order to fulfill the request for their authors).
So, a request to /posts?include=comments.author
should not include the associated comments in "linked", just the authors. I'm confused about how you'd chain your way into that relation from the primary resource of posts though, since the only way to get there is via the comments.
Anyway, more soon.
I was over thinking this, there is no conflict. I'll have this in by EOD.
@jugglinmike Jasmin requested this feature yesterday. Do you think you could finish the work I started on this PR?
It's a bit hard to tell what's what without this, see below: