Please don’t be offended.
By writing wrappers for the endpoint I had been complaining about, I assume you mean a wrapper containing something like …
if (response.status == 401 || (response.status == 400 && request.resource == '/users' && request.noSyntaxError))
refreshAccessToken();
Well, my whole point can be somewhat translated to saying that it would be cooler to just be able to do …
if (response.status == 401)
refreshAccessToken();
… and I solely blame the API design chosen for this specific endpoint as the reason why I’m not able to do that.
Sure, opinions about designs being good or bad are always subjective. But that’s exactly why I thought it’s worth sharing my thought process from above in this thread, because there might be different opinions on that.
So if “just write wrappers for it” is such an opinion, I must say I myself wouldn’t consider this a good suggestion. Because it pretty much fits for every design choice (good or bad) I guess. It sounds like “just deal with it”.
I also quickly looked at your wrapper library which (if I haven’t overlooked it) does not do automatic refreshing of expired access tokens. But I think that exactly my pseudo code example above shows why I consider different HTTP response status for the same problem/exception (= authentication failed) bad practice.
There is also this wrapper library which is a bit more popular, and it even does consider different exception types, but the handling of exactly the authentication exception I am talking about is just wrong. As you can see here, the TokenExpiredException is only thrown in case 401 Unauthorized is returned, which does not cover the 400 Bad Request response form the /users endpoint. It’s just another example of someone obviously not paying attention to what I call a poorly designed API endpoint.