/fishnet/status
lakinwecker opened this issue · 6 comments
In the experimental changes, you mention:
Key sent as header Authorization: Bearer <key>. In the future the key validation endpoint may be deprecated in favor of a GET /fishnet/status request, validating the header if present.
Does this endpoint currently require a key to access it? It does not appear to do so. Should it? If not, then what is the planned indicator for valid/invalid key?
Yeah, not sure about that. GET /fishnet/key/XXX feels wrong, but that proposal might not be the best either, because /fishnet/status does not (and should not) require a key.
Could add an optional key parameter, which is one of three values:
NOT_FOUND, REVOKED, ACTIVE or something
Or use the same status codes that we'd expect on authenticated endpoints, with the exception of giving the normal response if no Authorization header is present at all?
Sure, that also works for me. Although I'd honestly rather have a second end point for that. On success we could give you your current assigned work as a response
It's a bit weird to me that you might get a 4xx error for the same request that usually returns a 200 just because you included an authorization header. I guess 400 makes sense, but some of the other ones may not make as much sense.
how about a different endpoint that is a noop, always requires authorization, and rejects invalid keys with the usual status codes?
/fishnet/key?