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
{{ message }}
This repository has been archived by the owner on Feb 17, 2024. It is now read-only.
Is there any spec on how to describe multipart bodies? On the same note, is it ever possible to specify that a data is a binary stream? I don't see anything helpful in the spec, are there any recommendations on how to describe large (megabytes and more) data stream that can be ingested (or, for that matter, produced) by a w/s API?
Thank you.
The text was updated successfully, but these errors were encountered:
Hi, RAML does not really restrict you on what mime type you need to use. You can basically define what ever suits best for your use case. There are some "OOTB" mime types that are listed in the spec, but its more open to what you need. Does that answer your question?
I think that generally for streaming it's fine, just declare a content type of input/output. The reason I brought this up was I was struggling with defining an endpoint that will accept multipart/form-data, and I wanted to specify the parts. Though some of the parts are arbitrary streams, one part is a JSON object that I would like to describe as a type defined earlier. I can generally do that for query parameters, but I'm not sure it will work for multipart.
For sake of specificity, let's say I have to parts - a json object, and a binary stream.
/users:
queryParameters: # will those be recognized inside multipart/form-data by any implementations?
json: MyObject
binary: # how do I say it's a stream?
post:
body:
multipart/form-data: # I can't really specify contents here, can I?
Hi.
Is there any spec on how to describe multipart bodies? On the same note, is it ever possible to specify that a data is a binary stream? I don't see anything helpful in the spec, are there any recommendations on how to describe large (megabytes and more) data stream that can be ingested (or, for that matter, produced) by a w/s API?
Thank you.
The text was updated successfully, but these errors were encountered: