Since we dropped support for rack 1.X, we can replace some of our constants by Rack's constants. For instance, we had defined all supported http methods like Grape::Http::Headers::GET, Grape::Http::Headers::POST etc... but its already defined as Rack::GET, Rack::POST, etc... in Rack.
We also had redefined some Rack's constants in our code base like Grape::Env::RACK_INPUT, Grape::Env::RACK_REQUEST_FORM_HASH etc ... but these are Rack's internals and we should not rely on them and use Rack's constants Rack::INPUT, Rack::REQUEST_FORM_HASH.
At least, if Rack as major internal changes, Grape's will be in line with these changes even if it's a renaming or a drop. In the end, Grape is rack based and it all makes sense to do that since we were already using several Rack's utility functions.
Although, Grape should have a smaller memory footprint since we have less string literals.
Finally, I've changed Rack 3.0's integrations tests to make sure all our response headers are lowercased instead of looking if our internal headers are in lowercase. If makes more sense with #2425.
Motivation
Since we dropped support for rack 1.X, we can replace some of our constants by Rack's constants. For instance, we had defined all supported http methods like
Grape::Http::Headers::GET,Grape::Http::Headers::POSTetc... but its already defined asRack::GET,Rack::POST, etc... in Rack.We also had redefined some Rack's constants in our code base like
Grape::Env::RACK_INPUT,Grape::Env::RACK_REQUEST_FORM_HASHetc ... but these are Rack's internals and we should not rely on them and use Rack's constantsRack::INPUT,Rack::REQUEST_FORM_HASH.At least, if Rack as major internal changes, Grape's will be in line with these changes even if it's a renaming or a drop. In the end, Grape is rack based and it all makes sense to do that since we were already using several Rack's utility functions.
Although, Grape should have a smaller memory footprint since we have less string literals.
Finally, I've changed Rack 3.0's integrations tests to make sure all our response headers are lowercased instead of looking if our internal headers are in lowercase. If makes more sense with #2425.
Thanks