404 error when URL is valid

[bradanlane]

I recently encountered a 404 error while attempting to use the "groups" URL provided from the Web UI.

There are related issues #159 and #119

In both cases the real issue was data - or the lack there of - in the backend system.

I feel these point to a problem - especially for new users.

The 404 error is well known to internet users ...

"The website hosting server will typically generate a "404 Not Found" web page when a user attempts to follow a broken or dead link; hence the 404 error is one of the most recognizable errors encountered on the World Wide Web." - Wikipedia

At least for me, the 404 error does not suggest a data problem. It suggests a link or webpage problem.

I'm not sure why Adafruit IO uses 404 when the URL is correct but the data may be missing.

The 2 most appropriate options include:

• 400 Bad Request
• 500 Internal Server Error

[lorennorman]

Hey @bradanlane, thanks for this report, I'm getting up to speed here.

You said:

...the "groups" URL provided from the Web UI

Can you be specific: what URL it was? And where in the web ui are you seeing it?

[bradanlane]

From the io.adafruit.com user page where the user can create new feeds or groups, the user can view the generated urls. Here is a screenshot.

[lorennorman]

@bradanlane OK found them! And what did you try with those URLs? I'm trying to repro what you are reporting but I'm not having any luck.

• I made a new group with no feeds or data and pulled up this info.
• I visited the "Web" link in browser, worked as expected.
• I did a GET request to that API endpoint with my key, worked as expected.

Any other ideas for how to reproduce?

I looked at the other issues you linked, they make sense. They don't fetch a group or feed resource directly, they attempt to fetch actual data from inside them, which doesn't exist yet so naturally, 404. (We can definitely improve the error messages and the API wrapper, though!)

[bradanlane]

The issue came up as part of testing sending data to a "group".

I was performing a "post" operation.

The underlying issue is that the URL can be valid but the payload for the "post" may have incorrect information.

For example the payload may make reference to a non existing feed within a group.

The "404" error implies the URL is incorrect but the truth is the real error is from the backend system.

A backend service error is more appropriately a 500 series error.

When a user gets a 404 it specifically implies the URL is incorrect.

[tyeth]

I half agree with your statement, especially for browser urls, however I've just read on Mozilla an API can use 404 to indicate the endpoint is valid but a resource was not found, but then weirdly no mention on the 404 docs page. https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status#client_error_responses goto 400s then scroll, the menu link for 404 goes to 404 docs page [different]

It's also probably fairer to say it's a client error that they requested the wrong feed, rather than a server error, although I equally want it to be a server error that it couldn't process my request due to Auth/payload/whatever.

I swear there was a more modern code for your data is not acceptable yet was processable. The one I see suggests that relates to an Accept header which is different.

Anyway, 😂, it's all made better hopefully by the included error message saying what's wrong (where possible) instead of not, and the libraries being more graceful about such errors if expected.

[lorennorman]

@bradanlane i'd really love to dig in, reproduce the behavior you're seeing, and form some opinions on what you're saying! i can't do that without more detail.

I was performing a "post" operation.

post to what URL? with what payload? what instructions were you following? what did you expect to happen? what happened instead?

i can't comment on http codes etc until i know what exactly we're talking about.

thanks for taking the time to help us improve things.

[bradanlane]

I half agree with your statement, especially for browser urls, however I've just read on Mozilla an API can use 404 to indicate the endpoint is valid but a resource was not found ...

I feel there is a broader issue at play - the lack of informative return information

There are a number of instances where the backend does not or can not complete the action as the user expects. In some cases, it silently does nothing this example or the Python interface to AIO and the send_batch_data() method which does not return anything. Other times, like the one of this open issue it generates a 404 error but does not help with the cause.

Specific to @lorennorman 's request. At the time I opened this issue, the Python AIO library did not have methods for sending data to a group. This is PR 162. The workaround was to construct the dictionary according to the CircuitPython Implementation. (BTW: that repository also forgot to return the response from POST for both send_batch_data() and send_group_data())

[bradanlane]

It may make the most sense to prioritize PR 162 and insure both send_batch_data() and send_group_data() return the response from the _post() call.

With those addressed, I probably never would have mentioned the 404 error.

[lorennorman]

Ok, fair enough. I agree the API could use a holistic overhaul.

I'm closing this now as unreproducible since we weren't able to narrow down a specific HTTP method + URL that is erroneously 404ing.