docs: use descriptive string status names for auth errors #743
Conversation
|
Warning Rate limit exceeded@braden-w has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 4 minutes and 52 seconds before requesting another review. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. 📒 Files selected for processing (5)
✨ Finishing touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
braden-w
force-pushed
the
layer-7-auth-strings
branch
from
ec8c32a to
92ebe0f
Compare
Convert auth-related numeric status codes to descriptive strings:
- status(401) → status("Unauthorized")
- status(403) → status("Forbidden")
Files updated:
- tutorial/getting-started/guard
- tutorial/getting-started/encapsulation
- essential/plugin
- essential/best-practice
braden-w
force-pushed
the
layer-7-auth-strings
branch
from
92ebe0f to
a0478eb
Compare
|
Superseded by #747 (conversions) |
1 participant
This converts auth-related numeric status codes to descriptive string names across the guard, encapsulation, plugin, and best-practice documentation. Instead of
status(401)andstatus(403), the examples now usestatus("Unauthorized")andstatus("Forbidden").The motivation is simple: auth errors like "Unauthorized" are more self-documenting than their numeric equivalents. When scanning code or following a tutorial, the intent is immediately clear without needing to remember HTTP status code meanings. This is especially helpful for developers new to web APIs who might not have status codes memorized.
That said, this is a stylistic preference. Both forms work identically at runtime, so if you prefer keeping numeric codes for auth errors, feel free to reject this PR. I won't be offended.
This is part of a broader effort to improve the visibility of string status names in the documentation. Related PRs #739-#742 handle other status code categories, while #744-#745 add explicit examples showing that string names are supported.