I have a web service API call that returns BOTH:
1) First part is document metadata in the form of JSON (application/JSON)
2) and in the same response returns PDF bytes (application/pdf)
If HttpURLConnection.setRequestProperty("Accept", "application/JSON) is set only the first part is returned with is the metadata in the form of JSON.
If HttpURLConnection.setRequestProperty("Accept", "application/pdf) is set then only the later part of the response is returned in the form of PDF, starting with %PDF and ending with EOF.
The response indeed contains the metadata (first part) and PDF (later part). I can get one part, or the other by the setting above.
But in the single/same call, I need to get both metadata (JSON) and PDF, and I am not able to do so
I tried with the following and it does not return any result (the result is empty).
HttpURLConnection.setRequestProperty("Accept", "application/JSON;application/pdf") - this did not work.
The following configurations also returned empty results:
Instead of Accept, I also tried using "Content-Type, with the settings below, and the settings below return no (empty) value.
The code is similar to:
Questions: 1) What do I need to do to get both metadata (JSON) and PDF in the same call returned to me?
2) The StringBuffer gets either JSON, or PDF bytes but I need to get both.
3) Should I try Content-Type instead of Accept?
If you get that process to work, I would suggest not using a Reader to read the response. You mentioned "PDF bytes" and that's absolutely correct. Converting them to chars is going to damage the PDF and make it unreadable.
I can imagine a web service which returns JSON or PDF, depending on a request parameter. But trying to return both in the same response sounds like a big headache. JSON is characters, PDF is bytes. Trying to find where the JSON ends and the PDF starts also sounds like an annoying problem for the consumer of the service, and it's hard to say what the benefit of the "return both" version is.
I was hoping that the following added together for the value of "Accept" will return both JSON and PDF, but it returns empty.
It is the same API/URL with an exact value of the parameter.
- To this API, if I set "application/JSON", then it correctly returns metadata elements in JSON.
- On the contrary, if I set "application/pdf", it correctly returns only the PDF bytes (starting with %PDF and ending with EOF).
This API returns metadata (on the document) first and next the document bytes.
So you don't know for sure that there's a way to return both at once? Then it's almost certain that there isn't a way. Like I said before, that would be a really weird thing for the designer of the server to do. And since you can easily get both by making two calls, that's what I would recommend doing.
HTTP is a strict 1-to-1 request/response protocol. You make 1 request, you get 1 response. No more, no less. Repeat as needed.
So the only way to get 2 different documents from 1 request would be if you could pack them into 1 response.
That's not especially hard, since you could just cram them together into a single file and return that file's data as the response.
The challenge comes in un-cramming them on the client side. Standard HTML web pages don't have an un-cram feature. Maybe you could do some AJAX logic.
As far as demarcating the 2 types of documents, I can think of 2 options.
The most common solution is to simply send a ZIP archive or something similar. That has the advantage that pretty much anyone can unzip stuff.
The other solution is to use MIME encapsulation. MIME stands for Multipurpose Internet Mail Extensions and as its name implies, it was first developed to allow sending heterogeneous content in a single email. It's used for other things, though, including HTTP file upload. The essence of MIME is that there is a distinct header and metadata followed by content followed by a terminating header. The content is Base64-encoded to keep things that look like control characters from mucking up the transmission. Plus it allows for the fact that not all Internet nodes use ASCII/Unicode character sets (for example, IBM mainframes).
I'm going to be a "small government" candidate. I'll be the government. Just me. No one else.