You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Let me walk you through an example im working on. I'm implementing a type to encapsulate data required around uploads. At the moment it looks like this:
Rather than writing the type and range headers in every request, I've detirmined an upload should never be valid if these headers aren't included. So it doesn't make since to ever not write them in my endpoints when handling uploads.
Now I can easily get these required headers when implementing from_request() for the trait ParsePayload but I cant properly document them when implementing the Payload trait since there is no way to add headers.
Pro
My idea/request would be to add a additional function to the Payload trait called required_headers_schema() or just headers_schema() which should return the meta data for headers. If you look at the appeal of this change more broadly then types, It allows us to neatly encapsulate/bundle types that are always required together which helps to avoid duplication.
Con
One problem would be that poem-openapi is built in such a good way that consuming the library is automatically self documenting. When you state a header as an argument, that is enough. But this approach requires you to write it down in this theoretical required_headers_schema() and then implement it's source in ParsePayload from a request.
Im open to other ways of doing this. But the ultimate goal would be to have a struct as an argument in a endpoint like so:
Rather than writing common or standard arguments multiple times everywhere, If there is already a solution that im not aware do let me know. All thoughts I welcome, I would be more than happy to implement this myself.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Problem
Let me walk you through an example im working on. I'm implementing a type to encapsulate data required around uploads. At the moment it looks like this:
Rather than writing the type and range headers in every request, I've detirmined an upload should never be valid if these headers aren't included. So it doesn't make since to ever not write them in my endpoints when handling uploads.
Now I can easily get these required headers when implementing
from_request()
for the traitParsePayload
but I cant properly document them when implementing thePayload
trait since there is no way to add headers.Pro
My idea/request would be to add a additional function to the
Payload
trait calledrequired_headers_schema()
or justheaders_schema()
which should return the meta data for headers. If you look at the appeal of this change more broadly then types, It allows us to neatly encapsulate/bundle types that are always required together which helps to avoid duplication.Con
One problem would be that poem-openapi is built in such a good way that consuming the library is automatically self documenting. When you state a header as an argument, that is enough. But this approach requires you to write it down in this theoretical
required_headers_schema()
and then implement it's source inParsePayload
from a request.Im open to other ways of doing this. But the ultimate goal would be to have a struct as an argument in a endpoint like so:
Rather than writing common or standard arguments multiple times everywhere, If there is already a solution that im not aware do let me know. All thoughts I welcome, I would be more than happy to implement this myself.
Beta Was this translation helpful? Give feedback.
All reactions