adamluzsi
commented
1 year ago The request object here is a Rack::Request instance.
The Rack::Request object in Ruby's Rack library offers a foundational interface for incoming HTTP requests, primarily wrapping the raw HTTP data in a user-friendly, object-oriented way.
Path parameters in frameworks like rack-app, Sinatra, or Rails represent a more advanced layer, deriving from RESTful API design principles that transform URL path segments into parameters.
While Rack::Request processes raw HTTP data without inferring URL structure or routing, frameworks layered atop Rack introduce path parameters.
In Rack::App, you have access to the following parameter methods in your endpoint:
- path_segments_params
- only the params present in your path segments
- query_string_params
- only the params present in your query string
- validated_params
- Only the parameters passed your validation. Nothing else, to avoid hash key-value-based injections
- params
- will return validated_params if validation is specified
- Otherwise, it will merge all types of parameters into a hash map and return it.
I recognize that many frameworks adjust the request object, with some crafting their own. However, my goal with rack-app was to stay true to the core Rack experience.
We currently use the original rack/request object without any modifications. I understand your perspective that a rack/app/request object might reduce confusion in a RESTful API design, especially when the path parameter isn't accessed via the params method.
dekubu
Given
when I call the script
I get the following logging out put
@adamluzsi there is a difference between the params collections. I have observed that the request.params does not include path params or but it does contain params for forms.
can you please confirm If this is by design.