Looking forward to the performance improvements, to be sure.
Not that much new in the language I’m excited for - the null-conditional assignment seems nice.
Last update they broke dotnet watch test, though. I’ve tested that specifically on this one, but I’m wary of what else will be broken and remain broken for months.
Wouldn’t analog be a lot more precise?
Accurate, though, that’s a different story…
This actually looks kind of awesome.
Absolutely true, but Graph-QL has never pretended to be REST.
deleted by creator
Valid, but dumb.
good old 418, always appears when you really want a cup of coffee
Why even use HTTP, when you can just send bytes directly over the physical network card, right?
Because standards make it better for everyone. You’ve no idea when, who or in what context the error will happen or be received by.
It takes so little to return ProblemDetails, and improves the experience of devs using your API so much. Just do it. Stop thinking up edge cases and faffing about with excuses. Do it.
Please, please, please, PLEASE return error-codes and problem-details.
Here’s the RFC: https://www.rfc-editor.org/rfc/rfc9457.html
Then just return a 500 - Server error. Nice and obscure.
The ability to separate “something wrong with what you sent” (4XX) and “something wrong on the server” (5XX) is very valuable in itself.
Sorry to say, but if you put it on the internet the AI bots are going to gobble it down.
Only way to protect it is to not put it on the public net. If you add a challenge (login or something) it might stay unmolested, but that’s no longer a static site.
Would pass first validation, but fail when we try to send an email.
Successfully failed.
if i can email them and the user gets it - fine by me
This is the way.
Almost correct. ^.+@.+$
Too hard to validate properly to be worth it. Even if it is technically valid that’s insufficient. It must also work, and the easiest way to test that is to use it and verify that the user got what we sent.
I don’t validate emails, I test them.
That’s your email? OK, what did we send it? if we couldn’t send to it or the user can’t read it there’s no reason to accept it.
OK, maybe I do some light validation first, but I don’t trust the email address just because it’s email-address-shaped.
The day the nazi died - chumbawamba
JSON is valid YAML does not imply that YAML is valid JSON
no, we don’t