GraphQL supports returning both the error and data arrays for the same query/mutation, it would be nice when complexity limits are exceeded, if the data object still returned the complexity part of the mutation/query so we can see when it resets in a structured object.
That would be much easier than having to parse the error message for the info required. Which is the workaround used today.
Hello there @codyfrisch!
Thank you for that feedback.
I have added this as a feature request to our team
Security on the web is crucial. And as more and more websites adopt HTTPS over HTTP, API endpoints should do the same. If the API is developed with this potential error in mind, you should get an informative error. Informative errors tell you to access the endpoint via HTTPS rather than HTTP.
For example, a response might look like this:
This is a best-case scenario, because this error message tells you how to fix the problem: by making an HTTPS call, instead of HTTP.
However, when an API is built without this potential error case in mind, it can masquerade as other errors we’ll discuss later. With a very similar case, a less resilient API might produce the following:
500 Internal Server Error: One of the least helpful errors, 500 Internal Server Errors mean the server can’t handle the request. However, this can also happen when you pass incorrect or incomplete information to the API (or when it’s simply broken).
403 Forbidden: Depending on how the API infrastructure is set up, you might get a 403 Forbidden error. While you may have incorrect credentials, this could be the result of an undetected HTTP vs. HTTPS error as we discussed earlier.
404 Not Found: Some servers don’t have HTTP endpoints, so they return 404 errors. leading you to believe you’ve mistyped the endpoint URL or something similar.
Hello @codyfrisch, the previous ‘user’ is a bot