Full query string helpers #1604
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Considering the limitations of what we already have, these additions are most welcome. Ping me if you ever want to pair on a Cookbook addition for this. |
divarvel
force-pushed
the
full-query-string-helpers
branch
from
53359cb to
fdf3bea
Compare
divarvel
force-pushed
the
full-query-string-helpers
branch
from
fdf3bea to
e350e76
Compare
divarvel
force-pushed
the
full-query-string-helpers
branch
from
e350e76 to
1ae85d1
Compare
|
I'm not using haskell at work any more and I don't have time to revive this PR myself, but I still think it's a worthwhile addition to servant and am available to help anyone who wants to get it over the finish line. |
divarvel
force-pushed
the
full-query-string-helpers
branch
2 times, most recently
from
d387119 to
8dec489
Compare
tchoutri
approved these changes
Apr 23, 2024
divarvel
force-pushed
the
full-query-string-helpers
branch
from
8dec489 to
bcbd3d2
Compare
|
🎉 🎉 🎉 🎉 |
|
@tchoutri Since this PR broke backwards compatibility, we need to do a major version bump. Do we do that now, or just before the release? The advantage of doing it now is that then we don't have to remember that this PR changed the interface. |
|
@ysangkok yep let's do it right away. If you can't do it in the next 10 hours I'll do it in my morning. :) |
fendor
added a commit
to smucclaw/dsl
that referenced
this pull request
Jul 5, 2024
In order for LLMs to interact with the REST API (which is on the goals of the so-called LAG project), we need to provide an openapi3 compatible API. We do this by depending on 'servant-openapi3', and add appropriate instances for the servant REST API. Due to some issues, it seems like it is impossible (or very difficult), to make custom gpts invoke REST endpoints with JSON bodies... So, for now we simply send all parameters via Query Parameters. Until the next servant release, we have to explicitly name all query parameters. See haskell-servant/servant#1604 for the PR that we are interested in.
fendor
added a commit
to smucclaw/dsl
that referenced
this pull request
Jul 5, 2024
In order for LLMs to interact with the REST API (which is on the goals of the so-called LAG project), we need to provide an openapi3 compatible API. We do this by depending on 'servant-openapi3', and add appropriate instances for the servant REST API. Due to some issues, it seems like it is impossible (or very difficult), to make custom gpts invoke REST endpoints with JSON bodies... So, for now we simply send all parameters via Query Parameters. Until the next servant release, we have to explicitly name all query parameters. See haskell-servant/servant#1604 for the PR that we are interested in.
fendor
added a commit
to smucclaw/dsl
that referenced
this pull request
Jul 5, 2024
In order for LLMs to interact with the REST API (which is on the goals of the so-called LAG project), we need to provide an openapi3 compatible API. We do this by depending on 'servant-openapi3', and add appropriate instances for the servant REST API. Due to some issues, it seems like it is impossible (or very difficult), to make custom gpts invoke REST endpoints with JSON bodies... So, for now we simply send all parameters via Query Parameters. Until the next servant release, we have to explicitly name all query parameters. See haskell-servant/servant#1604 for the PR that we are interested in.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The goal of this PR is to adress a use-case that is not currently covered by servant: query strings with dynamic parameter names.
QueryParamand its friends are super useful, but extract the parameter name from a type-level string, so while this is useful in many cases, it cannot cover every use-case. A typical use-case would be implementing a search filter where filters are not static and can't be enumerated ahead of time.I'll propose two helpers, directly derived from a use case that came up at work:
[(ByteString, Maybe ByteString)]value. It cannot fail and provides raw access to the query string:QueryString :> Get '[JSON] [Book].This was the first version that i implemented for my concrete use-case at work, to get things going.
[]for a list of parameters:books?filter[search]=value&filter[author][name]=value. The corresponding type would beDeepQuery "filter" BookQuery :> Get '[JSON] [Book].This is based on what's currently used for my use-case at work.
Raw query string capture
Deep object query parsing