-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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鈥檒l occasionally send you account related emails.
Already on GitHub? Sign in to your account
馃搾 [v3 Maintenance]: Evaluate v3 Updates for Alignment with Express API and Document Findings #2715
Comments
One major deviation from Express is the combination of Request and Response into a single Ctx object. It might be worth considering splitting it into a Req and Res object. We could either pass these objects directly to the handler as Express does or access them through Express: app.get('/veggies/:name/color', function(req, res) {
if (veggies.has(req.params.name)) {
res.send(veggies.get(req.params.name).color)
} else {
res.sendStatus(404);
}
}); Fiber: app.Get("/veggies/:name/color", func(req fiber.Req, res fiber.Res) error {
if veg, ok := veggies[req.Params("name")]; ok {
return res.SendString(veg.Color)
} else {
return res.SendStatus(404)
}
}) Some notes:
If we decide not to go this route, it would be nice to write down that decision somewhere for posterity (unless it's already written down and I missed it..) |
Interesting idea, think this would have been considered before, but decided against it because of the mass of parameters in other functions |
There is also the fasthttp object or other general objects, where do we place them? |
I'll play around with my above suggestion in the coming weeks and try to come up with a summary of the impact. I will plan on making a separate issue or PR to track it. |
It looks like Ctx.Append has different behavior than res.append in Express. Ctx.Append adds to the existing header field, using comma separators. Example:
res.append will create a separate header field. Example:
By the way, fasthttp's equivalent, |
Current implementation seems to follow the RFC https://www.rfc-editor.org/rfc/rfc9110#field.vary for your example case. |
Agree that if the RFC suggests to use comma separated values for Vary, Fiber should do that. |
Maintenance Task Description
The purpose of this issue is to review the recent changes in v3 against the Express API to identify and document any deviations or convergences. This will assist in ensuring that our API remains as consistent as possible with Express, making it easier for users to transition or use both frameworks interchangeably.
Tasks
Expected Outcome
Checklist:
The text was updated successfully, but these errors were encountered: