Skip to content
This repository has been archived by the owner on Feb 17, 2024. It is now read-only.

multipart bodies #233

Closed
veselov opened this issue Jan 26, 2016 · 3 comments
Closed

multipart bodies #233

veselov opened this issue Jan 26, 2016 · 3 comments

Comments

@veselov
Copy link

veselov commented Jan 26, 2016

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.

@sichvoge
Copy link
Contributor

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?

@veselov
Copy link
Author

veselov commented Jan 26, 2016

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?

Thank you :)

@jstoiko
Copy link
Contributor

jstoiko commented Sep 26, 2019

@veselov: this blog post provides an answer. You may also describe you structured data as described here. Closing this ticket in favor of #704.

@jstoiko jstoiko closed this as completed Sep 26, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Development

No branches or pull requests

3 participants