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.

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

OpenAPI Spec - define an error structure #2974

Open
sebastian-bury opened this issue Jan 24, 2023 · 6 comments
Open

OpenAPI Spec - define an error structure #2974

sebastian-bury opened this issue Jan 24, 2023 · 6 comments

Comments

@sebastian-bury
Copy link
Contributor

Describe the feature request

Currently the specification does not provide an error structure. An error structure would help be able to gracefully and better handle errors if they are seen.

Background

No response

Solution suggestions

No response

@sebastian-bury
Copy link
Contributor Author

Additional notes:

Should have at least one error structure at paths:
- paths./api/client/features.get
- paths./api/client/features/{featureName}.get
- paths./api/client/metrics.post
- paths./api/client/register.post
- paths./health.get

Missing error schema at path:
- paths./api/client/metrics.post.responses.400

Should have required property 'errors' at path:
- paths./health.get.responses.500.schema.properties

@thomasheartman
Copy link
Contributor

@sebastian-bury Just out of curiosity: where did you get the data for the additional notes? Why should all those endpoints have at least one error structure etc? Not saying it's wrong at all, just curious where that came from ☺️

@gastonfournier
Copy link
Contributor

@sebastian-bury
Copy link
Contributor Author

@gastonfournier this came from an enterprise customer, DM me for the name, I would assume all endpoints could have errors such as unauthorized?

@gastonfournier
Copy link
Contributor

@gastonfournier this came from an enterprise customer, DM me for the name, I would assume all endpoints could have errors such as unauthorized?

Yes, that's why I kept this open with the list of endpoints. We need to prioritize this if this is important

@sebastian-bury
Copy link
Contributor Author

Yes, that's why I kept this open with the list of endpoints. We need to prioritize this if this is important

not important enough to prioritize currently, they haven't raised it recently

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Todo
Development

No branches or pull requests

3 participants