Exactly what it says.

For context: The reason this project exists is because none of the listed Ruby implementations allow you to switch request context (e.g. use a different Authorization header) across multiple requests; they all require setting global state. They also tend to assume APIs allow all the usual JSONAPI routes, and many don't (working with e.g. Rails' shallow routes often doesn't seem possible). In my use case, I needed to allow using different API keys on a per-request basis, and some of the routes of this API are, though compliant, somewhat complicated.

Once I had to start from scratch, I ended up building a framework for building Ruby clients that tries to balance between allowing more low-level per-request tweaks, leveraging the power of JSON API filter and includes, using a lot of laziness, but still making most of the complexity optional through semantically parsing the responses and fetching related records as-needed.

I appreciate the beauty of post.authors.map(&:comments), but I was less convinced of the need to use relational algebra to enable includes through Post.includes(author: :comments).find(1) when Post.fetch(url_opts: { id: 1 }, includes: ['author.comments']) works just fine. I get why other people like it, I just thought a simpler solution might be all that's necessary.

That said, the syntax isn't the main goal here; it's more about customization of routes and request details, which weren't provided by any solution I could find.