|
NtotheTC posted:I was horrified the first time I set up a rest API that would 404 if a resource wasn't found and had the SPA team complain that "none of the other API end points do this". They were right too, the API responses returned 200 with {"error": "<error code>"} as the body. 200 for everything is definitely an extant pattern. Honestly I think it's fine if it's documented and consistent and the responses are machine-readable (i.e. you don't need to parse error strings).
|
#
?
Jul 15, 2022 15:07
|
|
|
|
| # ? May 28, 2024 22:28 |
|
|
raminasi posted:200 for everything is definitely an extant pattern. Honestly I think it's fine if it's documented and consistent and the responses are machine-readable (i.e. you don't need to parse error strings). The HTTP status code conventions are somewhat ambigious, but while it can be helpful to define errors that matter to your application, there are a lot of tools and libraries that work best when the application follows the HTTP conventions. The tools doesn't have to know about a bespoke JSON field, or try to parse the response body. In my experience, there are always some framework errors that have not been converted to 200 correctly, so the client still always has to deal with HTTP-level 500 errors and application-level 200 errors. The best solution I've found is to use HTTP status codes, but include a response body if the code could refer to different scenarios that the client has to handle.
|
|
#
?
Jul 15, 2022 15:42
|
|
|
I think 400 and 404 are pretty much the only error codes which cover both business level errors ("you sent the wrong thing / you asked for a thing that doesn't exist") and protocol-level errors ("the json is not valid / the path is not valid"). So for those two types of errors, I can see a very good argument for returning 200 with a well-defined and potentially more detailed response object in the event of business-level errors, and reserving the actual 400 and 404 codes for protocol-level fuckups. (You can also make a case for 403 as being a dual error code, but I think it's an anti-pattern if you have to implement a business-level authz layer that's totally separate from the standard claims system. Also there's 409 which is weird because it's pretty much only a business-level error code.)
|
|
#
?
Jul 15, 2022 17:51
|
|
|
I dunno, I find the idea of the same URL sometimes returning 404 and sometimes 200 very, very, weird. 403 a lot less so.
|
|
#
?
Jul 15, 2022 18:04
|
|
|
"The path is not valid" and "you asked for a thing that doesn't exist" are the same thing, and the only way for them to be different are if you're leaking implementation details to the client.
|
|
#
?
Jul 15, 2022 19:39
|
|
|
raminasi posted:200 for everything is definitely an extant pattern. Honestly I think it's fine if it's documented and consistent and the responses are machine-readable (i.e. you don't need to parse error strings). If
|
|
#
?
Jul 15, 2022 20:20
|
|
|
Plorkyeran posted:"The path is not valid" and "you asked for a thing that doesn't exist" are the same thing, and the only way for them to be different are if you're leaking implementation details to the client.
|
|
#
?
Jul 15, 2022 20:43
|
|
|
API clients should not be constructing URLs to make requests to your API. Rather than telling clients "this user's ID is 123 and you can get the profile for a user at /users/$id", you should be telling them "the profile URL for this user is /users/123". The fact that /users/3236436456 and /dfsgkjhdfskgj probably hit different code paths in your application is an implementation detail.
|
|
#
?
Jul 15, 2022 21:35
|
|
|
OddObserver posted:I dunno, I find the idea of the same URL sometimes returning 404 and sometimes 200 very, very, weird. I'd expect the same behavior whether it's /product/123 or /product?id=123 or /product with "id=123" as a header. Which is that some numbers 200 and some 404. So if the same URL with different parameters is sometimes 404, that doesn't seem weird to me.
|
|
#
?
Jul 15, 2022 21:45
|
|
|
Plorkyeran posted:API clients should not be constructing URLs to make requests to your API. Rather than telling clients "this user's ID is 123 and you can get the profile for a user at /users/$id", you should be telling them "the profile URL for this user is /users/123". The fact that /users/3236436456 and /dfsgkjhdfskgj probably hit different code paths in your application is an implementation detail.
|
|
#
?
Jul 15, 2022 21:45
|
|
|
Volte posted:"/users/9783457" returning a 404 represents a different result than "/adsfojareff" returning a 404, and that's not an implementation detail unless your API is completely undocumented. Plorkyoren is correct imo. “/users/93762” and “/adsfohdvx” are both valid paths. If your server doesn’t have a resource for “/adsfohdvx” then that is not different from a client perspective than the server not having a resource at “/users/93762”.
|
|
#
?
Jul 15, 2022 22:52
|
|
|
Plorkyeran posted:API clients should not be constructing URLs to make requests to your API. Rather than telling clients "this user's ID is 123 and you can get the profile for a user at /users/$id", you should be telling them "the profile URL for this user is /users/123". The fact that /users/3236436456 and /dfsgkjhdfskgj probably hit different code paths in your application is an implementation detail. yeah ok, roy fielding
|
|
#
?
Jul 16, 2022 00:58
|
|
|
The real question is which status codes does Unity use?
|
|
#
?
Jul 16, 2022 02:41
|
|
|
pokeyman posted:The real question is which status codes does Unity use? 418 seems highly relevant to computer graphics?
|
|
#
?
Jul 16, 2022 02:48
|
|
|
Based on their recent acquisitions, 402 and 409, possibly 417 Of course that had to happen just as we were going into a Unity-based project.. hyphz fucked around with this message at 16:24 on Jul 16, 2022 |
|
#
?
Jul 16, 2022 16:17
|
|
|
OddObserver posted:418 seems highly relevant to computer graphics? Relevant if you're going to be putting the result on Steam
|
|
#
?
Jul 16, 2022 16:38
|
|
|
Volte posted:What you're referring to is REST and what you're saying is "all APIs should be RESTful" which some might call a hot take More of HATEOAS (which is such a hilariously bad name) than just REST, but HATEOAS is just "use hypertext semantics for everything". If your API isn't trying to be hypertext then just use whatever status codes you want. If you're doing something like GraphQL or RPC tunneled over HTTP then the HTTP status codes are obviously only applicable to the HTTP layer and a 200 {"error": "not found"} response is perfectly sensible.
|
|
#
?
Jul 16, 2022 21:05
|
|
|
Plorkyeran posted:More of HATEOAS (which is such a hilariously bad name) Would you say that you hate the name? 
|
|
#
?
Jul 16, 2022 21:11
|
|
|
Plorkyeran posted:Not really. The number of 4xx results you're producing isn't a particularly useful thing to measure in the first place, since that's by definition not something under your control. I run outages for a living, and the number of bizarre and hard to troubleshoot outages perpetuated by this idea is high enough to be irritating. To be clear, you're not fully wrong, but teams that just throw 4xx into a bucket and ignore it are missing the point that you can still cause 4xx errors through code. "Whoops, we put a bad link on our frontpage and suddenly 404s spike up' is something worth investigating, you just have to be more subtle about monitoring than simply 'error bad, cut ticket'.
|
|
#
?
Jul 16, 2022 21:16
|
|
|
I never learned how to pronounce HATEOAS. I normally go for something that sounds like “Hate O/S”.
|
|
#
?
Jul 16, 2022 22:25
|
|
|
lifg posted:I never learned how to pronounce HATEOAS. I normally go for something that sounds like “Hate O/S”. If you want to make everyone mad, you could say "hat-e-o's"
|
|
#
?
Jul 16, 2022 22:32
|
|
|
leper khan posted:If you want to make everyone mad, you could say "hat-e-o's" Ooh, I'm definitely stealing that.
|
|
#
?
Jul 16, 2022 22:39
|
|
|
YanniRotten posted:Just add password fuzzing, it logs you in if you're PRETTY close. I know you're joking, but I really do want some kind of 'eh, close enough' hashing algo for many applications. Falcon2001 posted:To be clear, you're not fully wrong, but teams that just throw 4xx into a bucket and ignore it are missing the point that you can still cause 4xx errors through code. "Whoops, we put a bad link on our frontpage and suddenly 404s spike up' is something worth investigating, you just have to be more subtle about monitoring than simply 'error bad, cut ticket'. Just to expand on this, 4xx errors tell me something is wrong with my hideous chain of balancing servers and proxy passing in my backend (or a 503 if something local to but behind haproxy is down). An error in the API itself can be for many reasons including the client sending bad requests and shouldn't fall into any 4xx code but something that needs to be described internally, but in almost any case still involves telling the client 'hey, that request went through, but something is fucky' with a 200. It works great until PHP decides to throw a wrench into the whole works with a bare 500 and buries the error in a log dir it maliciously changes the permissions on every restart... Ranzear fucked around with this message at 23:02 on Jul 16, 2022 |
|
#
?
Jul 16, 2022 22:57
|
|
|
i don't get why "use uri from response to find other thing" is such a big deal for apis
|
|
#
?
Jul 16, 2022 23:21
|
|
|
lifg posted:I never learned how to pronounce HATEOAS. I normally go for something that sounds like “Hate O/S”. Hatechoass
|
|
#
?
Jul 17, 2022 01:49
|
|
|
Falcon2001 posted:I run outages for a living, and the number of bizarre and hard to troubleshoot outages perpetuated by this idea is high enough to be irritating. Yeah, I think "measure" was the wrong word there. Large changes in the number of 4xx responses are interesting and worth monitoring, but the base rate mostly isn't. A dashboard which shows what percentage of your incoming requests are producing 4xx errors is just showing a meaningless number, but a dashboard which reports that your 4xx errors doubled in the last 24 hours is useful.
|
|
#
?
Jul 18, 2022 21:29
|
|
|
https://twitter.com/sheevink/status/1550997140280860673
|
|
#
?
Jul 24, 2022 15:21
|
|
|
That's way less clunky than other ways to detect those languages, this is unequivocal progress! Also lol.
|
|
#
?
Jul 24, 2022 17:26
|
|
|
does C really default to int for auto when passed a very clearly not-int
|
|
#
?
Jul 24, 2022 17:32
|
|
|
AFAIK C will always try to compile things as ints if it can't figure out their type. A good compiler will throw a warning but it won't actually error out if the program can be compiled.
|
|
#
?
Jul 24, 2022 17:39
|
|
|
iirc "auto" means something entirely different in C. In that particular case the statement is effectively "num = 9.5", which, missing a declarator, defaults to int. But I'm pretty sure that's been invalid syntax for a while. edit: C99 supposedly made it illegal to leave off the type declarator ("auto" is a STORAGE declarator in this case, akin to "static" or "const", not a TYPE declarator) so that means you have to compile as C89 OR C++11 (or higher).
|
|
#
?
Jul 24, 2022 17:40
|
|
|
Yeah C++ repurposed the 'auto' keyword because nobody ever used it with the original meaning so it didn't really break anything.
|
|
#
?
Jul 24, 2022 17:45
|
|
|
I built it using x86-64 gcc (trunk) on godbolt and got a warning plus the described behavior.
|
|
#
?
Jul 24, 2022 17:45
|
|
|
UraniumAnchor posted:iirc "auto" means something entirely different in C. In that particular case the statement is effectively "num = 9.5", which, missing a declarator, defaults to int. Yeah. The real horror here is in the story not tweeted, about how a computer toucher copy-pasted some C++ code from stackoverflow into a C library and then spent 3 months trying to figure out why the library wasn't behaving correctly
|
|
#
?
Jul 24, 2022 18:41
|
|
|
I mean, what is 19 but 18++? Sounds like C++ is doing its job, at least if you assume C = 18.
|
|
#
?
Jul 24, 2022 18:49
|
|
|
pokeyman posted:That's way less clunky than other ways to detect those languages, this is unequivocal progress! Nah, that's one of the worse ones. The best one (e.g. because it hasn't been deprecated, nor does it rely on compiler backcompat support) is taking sizeof 'a'.
|
|
#
?
Jul 24, 2022 18:52
|
|
|
Oh I thought I saw something about C23 changing auto to do proper type inference, so I assumed the tweet was about that.Xarn posted:Nah, that's one of the worse ones. The best one (e.g. because it hasn't been deprecated, nor does it rely on compiler backcompat support) is taking sizeof 'a'. Ok that one is better.
|
|
#
?
Jul 24, 2022 19:35
|
|
|
Wait, in which language is sizeof('a') not 1?
|
|
#
?
Jul 24, 2022 20:38
|
|
|
more falafel please posted:Wait, in which language is sizeof('a') not 1?
|
|
#
?
Jul 24, 2022 21:06
|
|
|
|
| # ? May 28, 2024 22:28 |
|
|
That's kinda hosed imo
|
|
#
?
Jul 24, 2022 21:07
|
|