• 0 Posts
  • 34 Comments
Joined 1 year ago
cake
Cake day: June 29th, 2023

help-circle

  • You are making several great points and I thank you for explaining them. I don’t even want to argue against any of them.

    I just feel like I’ve seen the USA murder muslims for a decade in the first degree, and now people are getting worked up over a second degree, and consider electing a con artist to prevent it.

    I’d rather have a reasonable person in office, that might respond to the public opinion, than someone who is purely focused on their own gain.






  • I wasn’t actively aware of this for most of my life until I recently visited a clients office. Buying someone a cup of coffee is an entire thing. There’s no free coffee. You have to purchase every single cup. And you first have to walk several minutes to the place where they sell the coffee. It blew my mind. I’m used to drinking one cup after the other without even giving it any thought. Coffee machine right next to me or around the corner. There, coffee incurs friction and cost.

    So when you invite someone for a cup of free coffee, this can open doors for you. I’m not kidding. People get all excited when you offer them a coffee break on your dime. And there’s levels to it too. There’s the regular coffee, and there’s the premium one. For the premium you have to walk longer and wait in line until the barista serves you.

    It’s a key component in office politics when coffee access is regulated.

    Why anyone would restrict access to legal stimulants in the office is unclear to me though. Put espresso machines on every desk!



  • I don’t necessarily disagree, but I have spent considerable time on this subject and can see merit in decoupling your own error signaling from the HTTP layer.

    No matter how you design your API, if you’re passing through additional layers, like load balancers and CDNs, you no longer have full control over all responses your clients receive. At this point it may be viable to always signal a successful backend connection with a 200, even if the process resulted in a failure.

    Going further, your API may include partial success scenarios, think batch processing, then the result could be a mix of success and failure that doesn’t translate to HTTP status.

    You could even argue that there is really no reason to couple your API so tightly with a concept of the transport layer it uses.


  • Respect the Accept header from the client. If they need JSON, send JSON, otherwise don’t.

    Repeating an HTTP status code in the body is redundant and error prone. Never do it.

    Error codes are great. Ensure to prefix yours and keep them unique.

    Error messages can be helpful, but often lead developers to just display them in the frontend, breaking i18n. Some people supply error messages in multiple languages, depending on the Accept-Language header.