• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Liutauras Vilda
  • Paul Clapham
Sheriffs:
  • paul wheaton
  • Tim Cooke
  • Henry Wong
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Piet Souris
Bartenders:
  • Mike London

HttpURLConnection - Obtain both JSON and PDF from the same request

 
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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:
HttpURLConnection.setRequestProperty("Accept", "application/*")
HttpURLConnection.setRequestProperty("Accept", "*/*")

Instead of Accept, I also tried using "Content-Type, with the settings below, and the settings below return no (empty) value.
HttpURLConnection.setRequestProperty("Content-Type", "application/*")
HttpURLConnection.setRequestProperty("Content-Type", "*/*")

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?





 
Bartender
Posts: 653
14
TypeScript Fedora
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Did you make the api? Is there documentation of how to use it?
 
Marshal
Posts: 27534
88
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Sam Gho
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I was hoping that the following added together for the value of "Accept" will return both JSON and PDF, but it returns empty.
"Accept", "application/JSON;application/pdf"


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.

Any thoughts?
 
Paul Clapham
Marshal
Posts: 27534
88
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Saloon Keeper
Posts: 26547
187
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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).
reply
    Bookmark Topic Watch Topic
  • New Topic