76

It's maddening how few people working with the internet don't know anything about the protocols that make it work. Web work, especially, I spend far too much time explaining how status codes, methods, content-types etc work, how they're used and basic fundamental shit about how to do the job of someone building internet applications and consumable services.

The following has played out at more than one company:

App: "Hey api, I need some data"
API: "200 (plain text response message, content-type application/json, 'internal server error')"
App: *blows the fuck up

*msg service team*

Me: "Getting a 200 with a plaintext response containing an internal server exception"
Team: "Yeah, what's the problem?"
Me: "...200 means success, the message suggests 500. Either way, it should be one of the error codes. We use the status code to determine how the application processes the request. What do the logs say?"
Team: "Log says that the user wasn't signed in. Can you not read the response message and make a decision?"
Me: "That status for that is 401. And no, that would require us to know every message you have verbatim, in this case, it doesn't even deserialize and causes an exception because it's not actually json."
Team: "Why 401?"
Me: "It's the code for unauthorized. It tells us to redirect the user to the sign in experience"
Team: "We can't authorize until the user signs in"
Me: *angermatopoeia* "Just, trust me. If a user isn't logged in, return 401, if they don't have permissions you send 403"
Team: *googles SO* "Internet says we can use 500"
Me: "That's server error, it says something blew up with an unhandled exception on your end. You've already established it was an auth issue in the logs."
Team: "But there's an error, why doesn't that work?"
Me: "It's generic. It's like me messaging you and saying, "your service is broken". It doesn't give us any insight into what went wrong or *how* we should attempt to troubleshoot the error or where it occurred. You already know what's wrong, so just tell me with the status code."
Team: "But it's ok, right, 500? It's an error?"
Me: "It puts all the troubleshooting responsibility on your consumer to investigate the error at every level. A precise error code could potentially prevent us from bothering you at all."
Team: "How so?"
Me: "Send 401, we know that it's a login issue, 403, something is wrong with the request, 404 we're hitting an endpoint that doesn't exist, 503 we know that the service can't be reached for some reason, 504 means the service exists, but timed out at the gateway or service. In the worst case we're able to triage who needs to be involved to solve the issue, make sense?"
Team: "Oh, sounds cool, so how do we do that?"
Me: "That's down to your technology, your team will need to implement it. Most frameworks handle it out of the box for many cases."
Team: "Ah, ok. We'll send a 500, that sound easiest"
Me: *..l.. -__- ..l..* "Ok, let's get into the other 5 problems with this situation..."

Moral of the story: If this is you: learn the protocol you're utilizing, provide metadata, and stop treating your customers like shit.

Comments
  • 24
    http: 200
    {"success": true, "error": "something went wrong"}

    Looks fine to me 🤷‍♂️

    Ok don't shoot me... it's a joke... fuck.... no need to be pulling a knife to my throoo......... *@C0D4 died*
  • 8
  • 9
    I can't understand how those brain dead people got a job in tech. This is the most basic shit even a slightly advanced user (!) will know and if a developer doesn't, he shouldn't be allowed anywhere near an HTTP or any APIs.
  • 15
    1XX Please wait
    2XX OK, here is it.
    3XX i dont have it here
    4XX you fucked up
    5XX i fucked up.
  • 2
    I'm sitting with a base one guy wrote. AspX/C# and it fluctuates wildly between sending http messages, errors, doing Ajax call and getting objects back with errors in or just... Whatever the fuck he felt like at the time.
    Feel your pain.
  • 2
    My god what a nightmare. How the hell this dumbfuck has a job?
  • 1
    @ArcaneEye
    Not gonna lie, that's one of the primary reasons I lean web API + spa, less risk of mixing paradigms on the server.
  • 0
    @stop If that's real...
  • 1
    @c3r38r170 seen it somewhere before, think it is.

    @SortOfTested yeah I'd like to, but there's no chance in hell we're migrating this thing anyway, so..
  • 2
    This is absolutely ridiculous. Can you give us the API endpoint so we can see if we can break it. They probably don't know about basic security either
  • 1
    @h@hjk101
    That's exactly what I thought.
    I don't want to know how many developers work with plain text passwords.
    "oh forgot you password? Type in you mail and we will send it back in plain text"
  • 1
    I feel so sorry for you... I can relate. Https://http.cat
  • 1
    It's partly you that is wrong. HTTP is a transport protocol, not an application protocol.

    Often the mapping of application specifics to HTTP is an anti-pattern. It has become popular due to naivety and REST. Most people don't understand the difference between REST and API.

    HTTP can be confusing as it has some specifics that blur the line between application and transport. Generally however the two should be separate.

    Whether you're using HTTP or an application protocol it should be possible to easily and formally work out what happened. And reasonably parse the response. Content type of JSON but normal text isn't ideal.
  • 3
    @RANTSMCPANTS
    Whereas I don't disagree with the bits you've stated that are factual. I lack the privilege, access and time to attempt to convert an entire industry to a different agreed standard.

    If you succeed in getting people to conduct sane domain and message design and maintain strict isolation per the OSI model, that'll be awesome. Rooting for you 📣
  • 0
    @SortOfTested There's not agreed standard. Just common practices.

    In all my time programming one of the biggest things is that people everywhere don't abstract.

    Sit in on support and people don't come to you with problems but instead solutions. Their own personal solutions.

    Your real problem is that actionable events aren't expressed well enough to be able to reasonably implement a reaction when they could be.

    Some might belong in HTTP naturally or some might make things worse if leaking across two layers unnecessarily coupling to disparate things. It's hard to tell without taking a look.

    The industry standard are APIs advertised as REST which does intend to make heavier use of HTTP specifics such as status codes but that aren't really REST and are badly implemented.

    In this case the status code would at least match the actionable so that's at least one down. In most cases people just match the concept not the purpose.
  • 1
    @RANTSMCPANTS
    Hey, my doodle, I'm trying to be cool, but you're kind of off in the weeds. Http is an application layer protocol that runs through the TCP transport layer protocol.

    https://odetocode.com/articles/...
  • 0
    @SortOfTested That's an example of where things are blurred. On the OSI model HTTP would mostly live in the App and Presentation layers. However that stack is just one of many stacks end to end. OSI as a whole is just transport or network. Confusing as it also contains transport. It also contains application which also exists outside of OSI in normal cases.

    Anyway HTTP is for transfer, IE, transport. It's in the business of passing messages around without being interested in reading those messages. It's the application doing that.

    As a specific solution implementing HTTP status codes can be a pandoras box. They're liable to do it as a box ticking exercise.

    I've seen it happen 9 times out of 10.

    Terrible things often happen. Machine readable is also really the point but this can have funny consequences if no examples given. Most commercial developers consider grepping the error message machine readable.
  • 1
    Probably there are plenty of corporate applications like that thanks to this great company microsoft which pissed on standards for last couple of years.
  • 0
    Um. What?
  • 1
    I’ve been employed a year. If I created that api frankly I would hang myself with no apology note.
  • 2
    I would do it somewhere isolated so I had the chance no one remembered I was alive and then I wasn’t.
  • 2
    { “user”: “rickh”, “status”: 404 }
Add Comment