Contributing support for Filtering, Pagination, and PATCH

[quantumew]

Great work on this library, loving it so far! I would like to contribute. I am planning on using this library to build out our SCIM implementation. There are 3 things missing that I need. Filtering, Pagination, and PATCH support. I noticed the contribution docs mention that I should discuss my intent to contribute with y'all, so here I am!

I have only given the internals a cursory glance but this would be my plan.

For filtering and pagination, I would just make sure the params get to the callbacks/handlers and then just make sure there is a mechanism to represent the proper details in the response.

For PATCH support I would like the library to support it, and do the proper validation but I am not sure what that would take. Perhaps for the PATCH endpoints, I just implement them in my app? Curious if you have any feedback?

[q-uint]

Thank you!

Filtering

I think filtering is a not that easy for support entirely. Most use cases are pretty easy and straightforward: filter=userName eq "john". But the following filter is also valid:

filter=emails[type eq "work" and value co "@example.com"] or ims[type eq "xmpp" and value co "@foo.com"]

Validating and parsing is not that complex. The problem here is how we could represent this so it is clear and easy to implement once passed on to the callback. RFC: Query Endpoints - Section 3.4.2

Pagination

Pagination could be implemented separate if needed. RFC: Pagination - Section 3.4.2.4

Patch

Before implementing patch we need at least some part filtering. RFC: Modifying with PATCH - Section 3.5.2

These are also the next features I wanted to implement/support. I don't know when I can get started with these. Feel free to share your thoughts on this and even tackle one of these features. The goal is to support every feature of SCIM in the end.

[quantumew]

Thanks for laying that out. I agree making a cogent querying API will require a bit of thought. Especially since consumers will be integrating with different databases. I wonder if the best approach is writing a core parser, then writing plugins for specific backends? I will likely get started on pagination shortly, then move onto querying and PATCH. Once I get to querying I will think about it a bit more then report back with a proposal. Thanks again!

[quantumew]

@di-wu I was just getting ready to start writing a SCIM filter parser, and I found this https://github.com/di-wu/scim-filter-parser. This is awesome! I have a question, what are you thoughts on supporting exposing the filters to the callbacks in two ways?

1. Create plugins/modules that know how to transpile the tokenized/parsed filters to specific query languages. For instance, I am using SQL so I would likely write that transpilation module first.

2. We can also expose the tokenized/parsed filter to the callback for consumers to implement their own transpilation, assuming it is not already a part of the SDK.

[q-uint]

Thanks, I hope the filter parser comes to good use!

I would prefer to only support exposing the tokenized/parsed filter. This does not take away that we can also provide a module that transpiles these filters to other query languages, but this should not influence the core module itself.

[quantumew]

@di-wu a separate module makes a lot of sense. I got most of the SQL transpilation written and I agree does not make sense in the core module. Too implementation specific 👍

[quantumew]

There is one last piece of this, supporting PATCH, figured I would update this issue, I am planning on holding off on doing that until I confirm I actually need to support it. I am not positive I do yet. Going to close this for now as my question was answered. Thanks for your help!