I understand that this isn’t really a topic regarding the spec, but I’m hoping someone might share their experience anyway.
I feel like inclusion has the potential to drastically stress a backend. While primary data can be subject to pagination, which in turn can also reduce load, no such approach seems to exist for inclusion.
This means that I can generate huge inclusion chains, even for a single resource, and cause the server to make extensive amounts of roundtrips with ever increasing resource counts. And even after all that, I can’t even trim down the size of the payload, as included records are not subject to pagination or truncation (however undesirable that may be in practice).
Obviously, when we implement our own queries, we make sure to construct them in a way that they perform as well as possible. But the API will be open to 3rd party developers who might maliciously or carelessly (but, most importantly, needlessly) construct queries that have potential to cause considerable load on different components of the infrastructure.
Upon realizing this, my first reaction was to establish resource (for example, time) quotas for queries. If a quota is exceeded, recursion brought on by inclusion is stopped and an error is returned instead.
However, this “solution” scares me as it might cause “friendly” queries to be aborted due to system load brought on by other factors.
I’d be happy to hear your thoughts