Comments (12)
When iterating the validation would be run
from openapi-json-schema-generator.
Sorry, I forgot to inform you about our decision. For our use case it was sufficient enough to just get the raw response back.
I also watched a part of the recent openAPI meeting but it seems that it takes more time until the different streaming content types (such as jsonlines) are official supported by openAPI. However, version 3.0.4, 3.1.1 and 3.2.0 support two format
options of the type
string that can be used to define either bytes or binary depending on the actual content (see this link for the version 3.0.4). The PR I previously posted is also merged.
from openapi-json-schema-generator.
Why are you sending json lines data as binary when plain text will work? It says that it is utf8 encoded so it could be string. Where is the spec definition of that content type and payload?
from openapi-json-schema-generator.
The approach to supporting different content types can be seen in the response body deserializer. They are explicitly handled on a case by case basis for types like
- plain text
- json
- octet stream
- multipart form data
from openapi-json-schema-generator.
Why are you sending json lines data as binary when plain text will work? It says that it is utf8 encoded so it could be string.
I am not sure as I joined the project after they decided on this content type. As it is not really a standardized content type, we are currently discussing if we should replace it with something else.
If we decide to stick with this content type, is it possible to support it in this library or is it required to be one of the more standardized types like the application/json
? There is one other type that could be useful in our case.
I also had a quick look on the deserializer of the response but I only find the cases for the last three content types but not for the plain text. Did I miss something?
from openapi-json-schema-generator.
My mistake, plain text is not on the list in python.
from openapi-json-schema-generator.
So my preference is not to support undefined content types unless there is significant prior work showing how the content type is sent and significant user need (lots of people want it).
Both of these look to be streamed json responses. Why not just get back the raw response, and deserialize it manually in a helper that you define? It is not clear how to handle streams in openapi. Should a function consume the response until it ends? What if it never ends? How should one terminate consumption of the response data early?
One way to return the data would be to return an io.IOBase context manager, that way the calling code could iterate on it and be responsible for closing it.
from openapi-json-schema-generator.
There is apparently some traction on officially supporting streaming response in the OpenAPI specification. They will have a meeting tomorrow where they, among other things, discuss on how to support it. For more information see this issue and PR.
One way to return the data would be to return an io.IOBase context manager, that way the calling code could iterate on it and be responsible for closing it.
This would also mean that the validation is not automatically checked by the library but the user needs to do it manually after iterating on it? I think for our use case it is sufficient if we have a way to just get the response from the server without the validation.
from openapi-json-schema-generator.
Should a function consume the response until it ends? What if it never ends? How should one terminate consumption of the response data early? One way to return the data would be to return an io.IOBase context manager, that way the calling code could iterate on it and be responsible for closing it.
Do you have a more detailed plan on how you would implement the functionality?
In our use case, we could work with either getting the raw response or supporting a different content type like json sequence.
As we need the streaming endpoint to work, is there a way I can help you with?
from openapi-json-schema-generator.
My responses described that a context would be returned and methods could be called on it to yield validated results.
Json sequence is an acceptable feature add to the code base because it has a rfc.
Paths forward here are
- you calling existing raw response returning methods and deserializing the bytes like you describe. You can validate payloads using document defined schemas.
- you submitting a PR with a proposed feature
- Me submitting a PR with the feature. I am applying to jobs at this time. If this was something that you want, you paying me for the work would be motivating. Otherwise my suggestion is option 1 or 2.
What were the results of the openapi meeting?
from openapi-json-schema-generator.
@Marcelo00 never heard back from you here. How would you like to move forward with this?
from openapi-json-schema-generator.
Closing this issue because the end user can use existing functionality (receive raw response and iterate through body deserializing each line of content using openapi document defined schemas) to meet their needs.
from openapi-json-schema-generator.
Related Issues (20)
- Java client, adds missing 3.1.0 schema validators HOT 1
- Java client, integrate servers into api configuration
- Java client, create component security schemes HOT 1
- Java client integrate component security schemes into ApiConfiguration
- [Announcement] 2024 Project Ideas HOT 1
- Java client, add requestBody feature
- Java client: add Response Object
- Java client: add Responses
- Java client, add header + serialization implementation
- [BUG] Error transforming enum values beginning with numbers HOT 1
- [REQ] add OAuth2SecurityScheme with the password flow HOT 1
- Java client, add operation
- [BUG][python] Missing quotes for array property in TypedDict definition HOT 2
- [BUG][python] Reference Error when using schema with optional properties HOT 2
- [BUG][python] Validation for nullable property HOT 3
- [REQ][python] Allow type: number format: float to ingest json integers HOT 7
- [BUG] Build failure on java 17 and 21 HOT 1
- [BUG][python] Crash when generating const property HOT 2
- [REQ][python] Improve generated new input type for anyOf schema HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from openapi-json-schema-generator.