Inconsistent HTTP status codes

[spoenemann]

The registry API is documented in https://open-vsx.org/swagger-ui/.

Currently the server returns status 200 and a JSON object { "error": "..." } for most occurring errors. This is inconsistent with HTTP standards and will likely cause problems when trying to interact with our API from other services.

The motivation for the current behavior was to avoid errors logged by the browser when fetching data from the registry (#23). @akosyakov do you remember in what context you experienced that?

[akosyakov]

Theia can have VS Code extensions installed which are not available on the open vsx (yet). In this case the extension widget try to check metadata there anyway.

[spoenemann]

Is there no way to suppress those errors? Would it help to check the existence with a HEAD or OPTIONS request first? Or should we have an explicit endpoint to check the existence of an extension?

We could also try whether the behavior is the same if we return the same JSON data with error message, but with a 404 status.

How do others handle such situations?

[spoenemann]

This is actually a very controversial issue:
https://bugs.chromium.org/p/chromium/issues/detail?id=124534

There is a "Hide network" checkbox in the Chrome Console settings (gear icon in the top right of the console). @akosyakov that is not a satisfying solution, right? It hides all network request errors.

I'd propose to add another endpoint /api/-/find?extensionId=foo.bar that offers the current behavior (return status 200 even if the extension is not found), and to change other endpoints to return proper status codes. That means /api/{namespace}/{extension} would return 404 for non-existing extensions, but you can use the new endpoint to check for existence without console errors.