status game

There’s a whole category of WTF rooted in not understanding what HTTP status codes mean. As a quick review, the basic pattern is:

• 100: Hey, I got your note.
• 200: Everything is cool
• 300: Look here
• 400: Client failed
• 418: I am a teapot
• 500: Server has failed

There are more specific codes within these ranges that provide more detail, but most codes don’t even get that far right.

for example, Abner‘s colleague found the following Ruby method.

def unique
  unless request.format == 'application/json'
    head 401
    return
  else

  status = nil
  if ["user_name", "email"].include? params[:id].to_s
    User.exists?(params[:id] => params[:value]) ? status = 200 : status = 404
  else
    status = 500
  end

  render :json => , :status => status
end

The purpose of this method is to do not have As the name suggests, it checks for uniqueness, but it simply checks if the username or email address exists in the system. Therefore, the first mistake here is comment– In these Rails routes, the method name is last Part of the URL – must be /users/user_name/unique?value=foo. Or, since you are only asked to send a request for JSON data, unique.json Technically it should be the last part of the path.

Let’s start with the guard that the client only returns JSON.They’re at least in the correct range – it’s a 400 error, but they’re probably definitely the worst one Within that range– 401: Unauthorized Tell your browser that you need to log in. The most correct error is: 415: Unsupported Media Typebut even regular 400 right Better.

Okay, let’s get past that and check out the following: params[:id] The field is either user_name or email. That makes the above comment even less accurate. id and value Query string field. However, assuming the query contains one of these values ​​as an ID, it performs a search within the database. Checks if there is a user with the requested value in that ID field.If so, we will return 200if not, return 404.

Hey, that’s all fine and acceptable. probably, 204: No Content It would be better. only Clients care about status codes, but we’re just nitpicking.

It’s time to request bad Things going wrong: 500 error. Returning “Something went wrong on the server” when the request is malformed is a bad choice.And for Abner, this especially 500 This error caused him a lot of trouble. I ended up wasting half a day trying to figure out why the server was failing even though it wasn’t failing at all.

And while there’s an obvious fix here (returning a better status code), it’s shocking to learn that the JavaScript client-side code relied on returning 500 for its own error handling. Probably.