-
-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[WIP] Adding swagger to moclojer #262
base: main
Are you sure you want to change the base?
Conversation
Important Review skippedIgnore keyword(s) in the title. Ignored keywords (2)
Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (invoked as PR comments)
Additionally, you can add CodeRabbit Configration File (
|
Having to specify the types of parameters is very bad, it complicates everything. parameters:
path:
username:
type: string We can assume that all parameters are It's possible to parse what comes after the |
@avelino I also think that parsing the uri seems more user friendly, and doesn't complicate our current implementation. One problem I have with ditching Anyways, I would definitely ditch the parameters field for now. Thinking a bit better about the body request, maybe that should be its own field, while the others, going with the signature you gave looks fine. - endpoint:
method: GET
;; {} is optional
path: /users/:age|int&name=avelino{&children=3|int}
body:
hello: string
bye: int
response:
status: 200
headers:
Content-Type: application/json
body: >
{
"hello": "{{body.hello}}!",
"user": "avelino is {{path.age}} years old and has {{path.children}} children"
} That's out of scope, I know, I just wanted to see how it would look like |
:headers (into | ||
{} | ||
(map (fn [[k v]] | ||
[(name k) (str v)])) | ||
(:headers response))}))) | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
does destructing [k v] account for repeating headers?
would map
returning ["something" 1 "something" 2] be treated without errors?
…etro compatibility
This is the implementation of closes #205 #226
I have added a flag to SWAGGER as an environment variable, which will enable the build for reitit routes. However, there are some additional steps required for reitit swagger. It requests that parameters such as name, query-params, path and body are specified, along with the response..
e.g:
Create a function that discovers all possible types of parameters or responses will be kind of verbose, but is not impossible, just want to be reasonable about our options.
So if we enable swagger we have to specify the parameter types or body or query parameters, what do you think?