Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Returning error responses which don't fit the HttpErrorResponseBody structure #124

Closed
WasabiFan opened this issue Aug 5, 2021 · 3 comments
Closed

Returning error responses which don't fit the HttpErrorResponseBody structure #124

WasabiFan opened this issue Aug 5, 2021 · 3 comments

Comments

@WasabiFan
Copy link

I'm porting an existing server to Dropshot as a proof-of-concept.

It seems from the docs that the only way to return an error (i.e., 4xx or 5xx status code) from a route handler is to return an HttpError. Unfortunately, this seems to impose a specific structure on the returned body (HttpErrorResponseBody). A custom implementation of the HttpTypedResponse type would seem to be appropriate here, but that type appears to be un-exported.

In my case, I have a "health" endpoint which returns the same health payload regardless of up/down status but uses the status code to indicate whether the service is healthy. I could also imagine arbitrary other cases where users might not want the prescribed structure of an HttpError.

Is there a way to work around this? A particular type I can return which will get me both appropriate body typing for OpenAPI specs and a non-success status code? Am I missing something?
@davepacheco
Copy link
Collaborator

That sounds like a reasonable thing to do! I think there are a couple of approaches here:

  • move forward with could use customisation of error presentation #39, which proposes customization of error bodies
  • have your API endpoint function return Response<Body>, where you can customize the response code and body structure. I believe the generated schema will be pretty generic in this case. It sounds like you want a more specific schema for the body as well.
  • have your API endpoint function return a custom type that impls HttpResponse (which does appear to be exported). The impl of metadata() will allow you to specify whatever JSON schema you want. This is essentially what HttpTypedResponse does. We could consider exporting HttpTypedResponse directly. But it's pretty small, and it can be replicated outside of Dropshot, so my bias is to keep the exported interface minimal.

@WasabiFan
Copy link
Author

Thanks for the reply!

I didn't consider checking up the chain from HttpTypedResponse to see if it could be replicated. That does sound like what I'd want to do. I'll try it out when I have some time.

From my end, I think the ability to return arbitrary status codes with a typed body would be good first-class functionality. It's a bit surprising how restricted the pre-built API is -- that isn't a problem, and is presumably a design goal. But it also means it's probably healthy to provide an escape hatch for those who need something outside of the guard rails. But then again, assuming the above works out, it evidently is possible for those who need it.

@davepacheco
Copy link
Collaborator

I hear that. Yeah, we sometimes prefer a smaller Dropshot API to ensure consistent behavior across our various consumers. Still, the escape hatches are important, and if we're using them a lot, we'll first-class them, too.

Closing because I think we've resolved this but please reopen if you run into trouble.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@davepacheco @WasabiFan