As we all know, because we’ve all gone and read the HTTP specification, when you CREATE a resource, you should get a 201 (Created) response code. It’s an API testing staple.
Ok, so not everyone has read it. That’s OK (200).
Let’s look at this API, it creates a user in the application.
When it returns, it returns a 200. That’s not OK, is it? (pun intended, of course). I mean, it’s not a 201, is that a bug? Should we call the HTTP police for that wrong status code?
Put that phone down
The truth is, if there was an HTTP police, they would be very busy. Nobody enforces HTTP status codes. Including 418 (I’m A Teapot).
Let’s look at another example, this time for reporting an error. Let’s try to get that user we just created. Oh no! The user’s gone missing. What status code should I get?
If the API developers are nice people (most of them are, I checked), they’ll return a 404 (NOT FOUND) status. Maybe, even a message in the response’s body.
But there’s no law saying that they must. They can, for example, return a generic 400 (BAD REQUEST). It’s not specific. It’s also not wrong. But just not what I expected.
The developers can even return a 50x (Server error), and they are still off the hook. No judge will convict them.
The Wild West of API Testing
Final example – a DELETE. When we delete a user, we get a 200. That’s OK. Really, OK.
But does it mean the user’s record was really deleted? In regulated applications, you can’t just delete stuff. You can mark it as deleted, and the deleted data can be accessed by admins, or other authorized users. If that’s the case, what does that OK really mean?
How OK is it?
HTTP codes are a convenience. They are there as information, but sometimes that information is not complete, or misleading, or has different meaning. There’s no standard, or enforcement. Just good courtesy.
And sometimes, that too, is OK.
If you want to feel ok about API testing, check out my devleoper’s workshop, or the tester’s workshop. Police not included.
0 Comments