You wouldn't put a card number in the path anyway (for obvious reasons). Far more sensible to put that in the request body.
And who's to say you can't put the reason in the body and still keep the code? What are you hurting by sending back 400? Unless you have lb's taking out nodes because of excessive 4xx's (which sounds like insanity) I don't see a reason _not_ to send 4xx's. At the very least it's a useful heuristic tool.
What are the obvious reasons? I'll presume you are referring to disclosure of the card number.
I had this discussion recently about 'security' with regard to X-Header versus ?query=param. Either it's http all plaintext on the network or it's http with tls all cyphertext on the network. Every bit in the http request and response is equivalent - verb, path, headers, body, etc - agree?
You could represent the card number as cyphertext in the request body, that's a good practice regardless of tls, but of course don't roll your own crypto. You could put that cyphertext in the path as well but if the cyphertext isn't stable that makes for a huge mess of paths.
You could make a case for trad 'combined' access logs situation with the path disclosed in log files. I can appreciate keeping uris 'clean' makes it safe to integrate a world of http monitoring tools, I would make this argument. In the case of the card represented in a stable cyphertext it's kinda cool to expose it safely to those tools.
If you grab something from an external service (say a cdn) then I believe by default the referrer will contain the url + query params, but not you X=supersecret header. Bit me once
>And who's to say you can't put the reason in the body and still keep the code?
Often systems will have application wide error handling to catch that and handle it in a systemic way. It can be a pain to short circuit that in a customizable off the shelf applications like Salesforce.
Philosophically, 4XX means the client did something wrong. Sending invalid data to a validation service is not doing something wrong.
> Philosophically, 4XX means the client did something wrong. Sending invalid data to a validation service is not doing something wrong.
The precise definition of 400 Bad Request is
The 400 (Bad Request) status code indicates that the server cannot or
will not process the request due to something that is perceived to be
a client error (e.g., malformed request syntax, invalid request
message framing, or deceptive request routing).
There's some room for interpretation for the phrase "process the request". If the only job of the service is to validate the request and return Valid or Invalid, then I guess yeah even an invalid request will have been processed, and 400 Bad Request may not be totally right. I think you could make a case for it! But I think you could also make a case for 200 OK with a more detailed error message and code in the body.
But if the service both validates the request and _then_ does something more substantial with it, I think 400 Bad Request is probably the most appropriate response to something that fails at step one.
Agreed. What else would you use 400 for? I don't see how sending back 400 is going to hurt.
The payoff of using 400 is you can watch your 400 rates with almost no effort (HTTP is well established and there's many many tools out there.) If you somehow start accidentally munging the card number sometimes or if your card processor starts doing wacky stuff you'll see a spike in 400 rates.
If it was really that troubling that declined cards are expected, I would personally at least want to see 200 come from the internal API and 400 go out to the client.
And if your "intermediate devices" start doing goofy stuff to 400's then you've got bigger problems... 4xx's shouldn't be taking nodes out of prod. That's wack.
In my opinion 404 should really mean the API endpoint doesn't exist and therefore the requested action did nothing. Using HTTP for business logic is like using ethernet frames with parts of IP. It is another level, HTTP is just a transport. 404 - not found, 5xx server problem, 301 - endpoint is now elsewhere etc. HTTP is for browser pages but you are actually making API requests using your JSON(or urlencoding or whatever)-based application protocol.
> 4xx's shouldn't be taking nodes out of prod. That's wack.
Welcome to AWS, where this is actually part of standard procedure (at least Elastic Beanstalk does this, not sure if it’s actually Elastic Loadbalancer under the hood).
Don't you love it when all configured backends/origins for a service are marked unhealthy through healthchecks, Amazon's load balancers route traffic to all origins.
Sounds like you popped in before mid-2017 when things were rough all around. F# is fully supported on .NET Core and, including tooling in VS. Give it a shot!
Yup. Although this doesn't really come into play with server code in my experience. I don't imagine I'd want to deal with it writing WPF / UWP things though where language support is more important
Even then I might just write the business logic in F# and glue things together with C#
> I don't imagine I'd want to deal with it writing WPF / UWP things though where language support is more important
As the article points out, there never has been any visual forms designer type stuff for F#, so if you're writing a GUI app with F#, it's best to wrap it in a C# shell anyway.
Which is fine, because you wanted to separate your core application logic from the GUI anyway, right?
> I might just write the business logic in F# and glue things together with C#
It's a perfectly reasonable way to go.
The only difficulty is that it simplifies things if you don't try to do all the fancy FP stuff at the boundary between the F# and C# parts of the app. While there are ways to pass, say, a tuple from F# to C# and cope with it on the C# side, it's better to limit types at this interface to things both languages support as first-class citizens: arrays, objects, simple scalars, etc.
Unix time is based on a hard calculation of UTC seconds, minutes, hours, days, and years. So UTC jumping causes a discontinuity in Unix time.
Im pretty sure the second graph is mislabeled (the UTC second after 23:59:60 should be 00:00:00), but Unix time takes 23:59:60 to mean the same as 00:00:00. So 23:59:60.5 is also the same as 00:00:00.5, and so on. If you parsed the Unix time into a readable timestamp, it would tell you it's the first second of the next day for two seconds.
> How does UTC jumping around affect this? If a leap second is removed it doesn't mean you've waited 0 seconds.
No, but it means UNIX time does not advance by exactly one second per elapsed second. Instead it advances by either 0 or 2.
> It's not Unix time doing that. It's UTC.
It's also unix time. unix time is (86400 * days_since_epoch + seconds_since_midnight). A leap second means a day is not 86400 seconds, and thus you'll either get a skip or a repeat on midnight rollover.
> How does UTC jumping around affect this? If a leap second is removed it doesn't mean you've waited 0 seconds
The OP did not make this claim. He said that waiting 1s does not necessarily increase the Unix time by one second - not the other way around.
Or how my highschool math teacher put it: Every time it rains, the street gets wet. But not every time the street is wet, it rained - maybe my dog just took a leak....
UTC jumping around affects it if you're basing your time-elapsed measure by checking "time.now() - previouslySavedTime". That can give you a negative value, if e.g. your 1/2-second elapsed time crossed a leap second.
For one, it's single threaded (last I checked). It also seems to be built on a big heap of messy Java.
Check out Cuberite for comparison. It's a Minecraft server built from the ground up in C++ and it's waaaaaaaay faster than the official server. Advantages of a rewrite I suppose...
There are two completely separate lines of Minecraft ("Java Edition" for PCs vs "Bedrock Edition" for PCs/game consoles/...), so they've done a rewrite, but not dared kill off the original product, because they aren't compatible.
Not just compatible, the game mechanics aren't even the same :(
I think the end of the line for Java Edition will come at some point, but I also think they know perfectly well that they cannot do that prematurely, and we're very much still in "premature" territory.
If we hadn't looked to the stars in the first place, then we'd have a much worse idea of what is wrong with the ground than we currently do and technologies such as solar panels might not have entered commercial development. We are going to find this much more difficult to fix without a space industry.
there’s always going to be issues that need solving.
but it’s these extremely conservative ideas that give me pause.
we can’t solve everything. we need to go to the stars before another asteroid strikes and wipes us all out.
I feel like this is a universal absolute, doubly so when it comes to enterprise apps (the lone exception being when we switched from Lotus Notes to Gmail -- then only half the company hated the change).
I would've liked to know how long the changes were in place and how it affected productivity metrics, especially the amount of training time spent on new users. As is, the article seems kind of obvious. Enterprise users abhor change; who knew?
> Just like you wouldn’t appreciate a dictionary with only 10 words per page (so many pages to flip through!)
This also makes me question the veracity of the article. It's a really terrible metaphor that makes me wonder if they were _solely_ concerned with pretty design on the outset.
I want a dictionary that shows me 1 word per page, with a search bar. The page flipping functionality is useless and can be removed entirely. It's a bad workflow.
I can definitely say that over the past 20 years, our in-house LoB app has developed some really bad workflows as well (business changes a lot over 20 years). Removing these bad workflows would give us back a ton of screen real estate without losing productivity.
The causality is backwards. I don't want to create whitespace by changing the design and ruining the functionality. I want to change the functionality which will create more whitespace and allow room for beautiful design.
>> Just like you wouldn’t appreciate a dictionary with only 10 words per page (so many pages to flip through!)
> This also makes me question the veracity of the article.
Personally I thought the opposite, I find it a fantastic quote from the article as it exactly describes the problem:
Things that used to take a single click taking multiple clicks with slow animations between them because "design" and information not anymore visible on one page even though the human visual system is very well optimized to deal with that vs waiting for multiple screens.
