Question about the status code in the rule

[greenlaw110]

In the rules section it says:

• GET '/' return status code 200 with empty body
• GET '/user/:id' return status code 200 with the id
• POST '/user' return status code 200 with empty body

As per HTTP standard, empty body should have a 204 response, and POST success normally indicates a create success, thus it might be good to return 201 Created.

[tbrand]

Agree but it requires a lot of efforts to fix. lol

[waghanza]

@tbrand I can do it ... question is to write rules that cover all use cases (what about https://www.techempower.com/benchmarks/)

[OvermindDL1]

Rules are good, the more detailed the better.

Like not just saying things like GET and 204 with empty body or so, but even more detailed so that the implementations remain good comparisons, things like routing must be performed a certain way or validation must be done on x-and-x, etc...

[waghanza]

@tbrand @OvermindDL1 digging for any benchmarks, and how developers use it / implement it
it appears that on most case, there is only 1 endpoint.

What do you think about that ?

I think it COULD be helpful to decrease our rule set to only one endpoint implementation, for example, it could be a GET to /hello/:name to ensure routing and param parsing.

The advantage I see :

• simpler to implement -> to increase community
• can focus on standard -> HTTP header, SO_REUSEPORT ...
• simplify benchmarker code
• less time to run (or we can publish more ofter with cloud results)

[OvermindDL1]

I'd think multiple routes are fine as there tend to be many in any given application and they are generally only another line of code in most of them anyway. Plus keeping them separate allows you to benchmark the different parts and handling of a framework as well.