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

Header validation DSL #1371

Open
thedrow opened this Issue Apr 26, 2016 · 11 comments

Comments

Projects
None yet
5 participants
@thedrow

thedrow commented Apr 26, 2016

Currently there is no way to validate headers with Grape using the DSL.
It'd be useful to be able to specify that a header must be present or must be equal to something without coding it manually.
Providing a header validation DSL can help you say things like:

  • The client should never ask to cache the request using Cache-Control
  • The server only responds in UTF-8 charset.
  • A custom header must be present and equal to "Yes"
@LeFnord

This comment has been minimized.

Show comment
Hide comment
@LeFnord

LeFnord Apr 26, 2016

Member

for grape-swagger we had a similar discussion …
one approach was, to define the header parameters for the request in the same manner as the other one, e.g.:

params do
  requires :X-Rate-Limit-Limit, type: Integer, documentation: {desc: '…', param_type: 'header' }
end

this way, it could be used the params validations, what did you think?
on the other side, the request params are consistent

at the moment, the header key from the desc block would be used, with the downside, you mentioned

Member

LeFnord commented Apr 26, 2016

for grape-swagger we had a similar discussion …
one approach was, to define the header parameters for the request in the same manner as the other one, e.g.:

params do
  requires :X-Rate-Limit-Limit, type: Integer, documentation: {desc: '…', param_type: 'header' }
end

this way, it could be used the params validations, what did you think?
on the other side, the request params are consistent

at the moment, the header key from the desc block would be used, with the downside, you mentioned

@dblock

This comment has been minimized.

Show comment
Hide comment
@dblock

dblock Apr 26, 2016

Member

IMO we want headers do just like params do reusing the exact implementation of params.

Member

dblock commented Apr 26, 2016

IMO we want headers do just like params do reusing the exact implementation of params.

@thedrow

This comment has been minimized.

Show comment
Hide comment
@thedrow

thedrow Apr 26, 2016

@dblock Exactly what I was going to say

thedrow commented Apr 26, 2016

@dblock Exactly what I was going to say

@pynixwang

This comment has been minimized.

Show comment
Hide comment
@pynixwang

pynixwang Feb 20, 2017

maybe we also need
body Entity

to simplify json schema from client.

with

params do
  requires :user
end

client must post json like this

{
  "user":
    {
      "id":"123"
    }
}

I just want

{
  "id":"123"
}

pynixwang commented Feb 20, 2017

maybe we also need
body Entity

to simplify json schema from client.

with

params do
  requires :user
end

client must post json like this

{
  "user":
    {
      "id":"123"
    }
}

I just want

{
  "id":"123"
}
@dblock

This comment has been minimized.

Show comment
Hide comment
@dblock

dblock Feb 20, 2017

Member

@pynixwang Your example should be

params do
  requires :id
end

Body is read into params as long as content-type is JSON or form or such.

Member

dblock commented Feb 20, 2017

@pynixwang Your example should be

params do
  requires :id
end

Body is read into params as long as content-type is JSON or form or such.

@pynixwang

This comment has been minimized.

Show comment
Hide comment
@pynixwang

pynixwang Feb 20, 2017

@dblock swagger-doc show as formData, I want a Model Scheme. and I want just accept json not form...

@dblock swagger-doc show as formData, I want a Model Scheme. and I want just accept json not form...

@dblock

This comment has been minimized.

Show comment
Hide comment
@dblock

dblock Feb 20, 2017

Member

Swagger is a whole other issue, but you cannot have it both ways - call something a userand expect the DSL to ignore it. You can however move the declarations out of the params part, and then use that.

Member

dblock commented Feb 20, 2017

Swagger is a whole other issue, but you cannot have it both ways - call something a userand expect the DSL to ignore it. You can however move the declarations out of the params part, and then use that.

@pynixwang

This comment has been minimized.

Show comment
Hide comment
@pynixwang

pynixwang Feb 21, 2017

make a body DSL like
body :user

and do not merge hash into params, just put into prams so we can reference like params[user]

or new reference body[:user] or just body or something like object and collection for array.

make a body DSL like
body :user

and do not merge hash into params, just put into prams so we can reference like params[user]

or new reference body[:user] or just body or something like object and collection for array.

@dblock

This comment has been minimized.

Show comment
Hide comment
@dblock

dblock Feb 21, 2017

Member

@pynixwang Feel free to enable this with a pull request.

Member

dblock commented Feb 21, 2017

@pynixwang Feel free to enable this with a pull request.

@pynixwang

This comment has been minimized.

Show comment
Hide comment

@dblock I 'm trying.

@MiralDesai

This comment has been minimized.

Show comment
Hide comment
@MiralDesai

MiralDesai May 1, 2018

+1 I know this is old, but still feel it's relevant. We're half way there in that we can define headers to be re required or not inside the desc block See here. but it would also be nice to be able to validate them with the all_or_none_of, at_least_one_ofetc methods already present for params

MiralDesai commented May 1, 2018

+1 I know this is old, but still feel it's relevant. We're half way there in that we can define headers to be re required or not inside the desc block See here. but it would also be nice to be able to validate them with the all_or_none_of, at_least_one_ofetc methods already present for params

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment