On Mon, May 24, 2021 at 3:41 PM Alexandru Pătrănescu <dreal...@gmail.com> wrote:
> On Mon, May 24, 2021 at 10:25 PM Michael C <m...@michaelcullum.com> wrote: > >> On Mon, 24 May 2021, 18:06 Larry Garfield, <la...@garfieldtech.com> >> wrote: >> > On Mon, May 24, 2021, at 10:57 AM, Matthew Weier O'Phinney wrote: >>> >>> <snip> > A http request method enum will not be complete for usage in all places > because in fact a http method is just a string as I should be able to send > BLABLABLA in my http client if I want to. Or receive it on my server. And > because of that, they cannot be easily used as types in PSR-7, PSR-18. I > think using string constants is fine here. > Same thing for http response code; eventually Cloudflare will return a 524 > timeout response code that is not included. Well, for this actually it can > be defined as an integer between 100 and 599 but that's not practical. > > So only StatusCategory enum looks good from my point of view. > When it comes to HTTP status codes and request methods, the IETF has left them deliberately open-ended. That said: - The specification allows for flexibility to add more within certain parameters, and - They have a process for petitioning to make new additions canonical. What the current http-message-util does is codify the ones that are already canonical. The primary reason to use them is not so much to consume and validate an HTTP message, but to _create_ one. For example, with HTTP clients, having the ability to select an enum for a given request method helps prevent potential typos. If you are choosing to use a non-canonical request method, you will need to deliberately steer clear from using the enum, which in turn should trigger a bit of extra review on either your part or your team's part. Similarly, for status codes, these are generally of interest when creating the response. The way we've defined the constants is to use their semantic name as the constant name, which in turn makes it easier to indicate _intent_ as you create the response. Yes, these _can_ also be used for validations, or if you want to see if a request method or status code matches a known canonical value, but, as noted, you should always be able to fall back to either range checks or a regexp. As such, I'd argue that having enums is a _starting point_ for message validation, and an important one, and a _requirement_ for users creating messages, with the understanding that they _can_ break out of the defined values as needed, again, as long as they provide values that fit in the standard ranges or ABNF. > > >> >>> There's likely other enums that it makes sense to have a single >>> definition of, but don't fit neatly into a single existing PSR/util package. >>> >>> -- >>> Larry Garfield >>> la...@garfieldtech.com >>> >>> > Regards, > Alex > > -- > You received this message because you are subscribed to the Google Groups > "PHP Framework Interoperability Group" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to php-fig+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/php-fig/CAAwdEzBQvW3SaJH8fvzjN5rsSuEB280e2iab_JEcJ-cbVoesJQ%40mail.gmail.com > <https://groups.google.com/d/msgid/php-fig/CAAwdEzBQvW3SaJH8fvzjN5rsSuEB280e2iab_JEcJ-cbVoesJQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- Matthew Weier O'Phinney mweierophin...@gmail.com https://mwop.net/ he/him -- You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAJp_myWCuyx10TvjbV5diCWTUz44GUZ70b9h5WQAwQvDDctRug%40mail.gmail.com.
