Closed psamsotha closed 8 years ago
Or maybe, just for multipart, whenever it's any other type, just add some placeholder content like <<binary data>>
, so that's what would show up in the snippet. Just throwing an idea out there.
I haven't got a full understanding of how and when REST Assured converts content to a different type, but I can see no reason why REST Docs can't support File
at the very least. IIRC, the problem with an InputStream
was it could then only be read once. It could be wrapped in a BufferedInputStream
but, depending on size, there's no guarantee that would work. I'll double-check that this is indeed the case.
The conversion happens in MultiPartInternal.getContentBody()
:
def getContentBody() {
if (content instanceof NoParameterValue) {
content = "";
}
if (content instanceof File) {
new FileBody(content, fileName, mimeType ?: OCTET_STREAM, charset)
} else if (content instanceof InputStream) {
returnInputStreamBody()
} else if (content instanceof byte[]) {
content = new ByteArrayInputStream(content)
returnInputStreamBody()
} else if (content instanceof String) {
returnStringBody(content)
} else if (content != null) {
returnStringBody(content.toString())
} else {
throw new IllegalArgumentException("Illegal content: $content")
}
}
Note that when the content is a byte[]
, it's changed to a ByteArrayInputStream
. All other content types are left as-is. This appears to be the case across REST Assured 2.x
With RestAssured multipart support, we can go things like
The problem with this though is the
RestAssuredRequestConverter
, when it tries to convert the content. Only a few types are supportedYou would think that the
byte[]
should work, but somewhere in the process, before the spec is build, it converts thebyte[]
into aByteArrayInpuStream
, so it fails like with all the other types.The other types (
InputStream
andFile
) don't get converted, so you get the same exception as above, but with the respective type in the message.As a solution, I was thinking maybe just handle the easiest case, checking for the
ByteArrayInputStream
, in which you can easily convert the to abyte[]
without RestAssured being affected. The problems I see with this is that 1. You don't cover all other types, 2. It is dependent on the RestAssured implementation not changing. For the second point maybe just write a test to fail, if it does ever change, cross that bridge if it ever gets to that point. Not the best idea, but somehing I could live with.Or maybe there is some other way, through some RestAssured APIs to change this behavior, without needing to touch RestDocs. Maybe some preprocess filtering. I don't know, I am no RestAssured expert.
Maybe @johanhaleby has some ideas on how this problem can best be solved.
Below is a complete runnable test that reproduces the errors.