3

Here's the scenario:

I want to make some HTTP API calls using Javascript, and have the response load in the browser. The requests might be GET, POST, PUT or DELETE, and the response that comes back could be any type of content - it might be HTML, JSON, XML, or an images, document, binary content, or whatever. I'd like the response to be handled by the browser in exactly the same way as it would if the browser was loading a new page.

The problem is that I can't see any way to load the arbitrary content that I receive.

Obviously it's possible to load content into the DOM, but that only allows me to deal with HTML. (And potentially embedding some media types such as Images etc.) I don't see any obvious way to deal with embedding response types such as JSON and XML without having to construct special cases for how to renderer each type into HTML.

I've considered if there might be some work around involving frames or changing window.location to load the content, but I can't see any way to make it work.

Is it at all possible to do what I'm looking for, or can you suggest any elegant workarounds that might help?

Edit:

For a bit more background - This is for some work on an API browser. I've no problem doing what I need with GET and POST - it's PUT and DELETE that are awkward, since I can't support them directly with HTML. At the moment the implementation uses some server-side trickery and a hidden _method field on the form, that allows POST requests to be overloaded into PUT/DELETE/OPTIONS/whatever, but ideally I'd like to take that logic out of the server side, and do the equivalent using javascript.

Right now I don't think it's actually do-able, but I'm hoping that someone can prove me wrong, or find an elegant work-around.

Improve this question
4
  • One of the alternatives is to provide the resource (file) as a link and on click the file gets downloaded on the client. Any supporting software/application on the client can run/open the file. This solution is outside the browser. Commented Dec 13, 2011 at 11:33
  • That won't work because it'll only let me perform GET requests. Commented Dec 13, 2011 at 11:43
  • 1
    I'd like the response to be handled by the browser in exactly the same way as it would if the browser was loading a new page. Then load a new page. Your browser already has this functionality. Commented Dec 13, 2011 at 13:35
  • That implies it'll be making a GET request (or POST, for a POSTed form), which isn't sufficient for what I want. I want to also be able to load a new page in response to PUT and DELETE requests. Commented Dec 13, 2011 at 13:41

3 Answers 3

Reset to default
1

I wonder if you can open a new window or create an iframe where the URL you pass to the window or iframe is not an absolute URL for the resource on the web, but a data uri. You'd need to sniff out the mime-type of the response and then encode the body of the response.

No idea if it'd work, but I'd be interested to hear if you do manage to achieve it.

Other things to explore: the BlobBuilder (an HTML5 feature) and creating a "sourceless" iframe (where the src is just about:blank) with a custom mime type and then use document.write to write into the iframe document (some of the code in AppleOfMyIframe could be of use).

Improve this answer
Sign up to request clarification or add additional context in comments.

3 Comments

Using data URIs looks like the most promising option. (Possibly constructing those URIs using BlobBuilder.)
aminus.net/wiki/Okapi uses an iframe, and allows you to select document.write, body.innerHTML, or a data URL for document.location, because each has their pros and cons. You might consider giving your users the same choice.
Interesting looking project, that!
1

I think the data URIs could work but ultimately I kind of feel you'd be removing a teeny bit of server-side parsing (your POST parameter) at the expense of introducing complexity elsewhere.

You could use the AJAX and redirection combo if you didn't care about the fact that you'd be using an intermediate GET request to actually load the response, but guessing you probably do so that's not viable.

Since you don't want to use AJAX and insert into the DOM I actually think your form field at this point is the most elegant, or at least most robust solution. No messing around with iframes, new windows or similar and one request yields one response, at the expense of having to possibly reinterpret a POST as something else server-side.

I can't think of a better solution than the one you currently have in place.

Improve this answer

4 Comments

Yeah, I think I've come to the conclusion that there's not any clean-enough way to do it. I don't mind inserting into the DOM, but it's not viable unless theres a general purpose way of inserting any arbitrary content with any arbitrary mimetype.
Well, if the server can return a response that is a URL to the resource, instead of actually returning the resource, then the browser could simply open a new window or iframe, with that URL. It does take away the elegance of your REST API, but may be practical. You'd need to obfuscate URLs if the data is private. Perhaps this behaviour would only take place if a specific custom header is sent with the request.
@Premasagar "Well, if the server can return a response that is a URL to the resource, instead of actually returning the resource" - Defeats the purpose of what I'm trying to do. I'm trying to remove server-side fudging, and have the "send a form using PUT" behavior be entirely client-side.
Sure. As long as you can do it :)
0

As you probably understand yourself, forms only allow POST and GET HTTP request. The only way to do PUT and DELETE using javascript is through AJAX (XMLHttpRequest); which is something you dont want since you specifically require your code to refresh the page on each HTTP API call and then show the raw response on the browser (either as XML or JSON or anything else..).

But really if what you;re trying to do is as simple as

  1. making an HTTP API CALL using javascript.
  2. Load the XML or JSON response that contains raw data on GET/POST (besides parsing them and appending to the DOM)

then..I don't think that the solution should be anything fancier than just redirection really:

<html>
<head>
   <script type="text/javascript">
       var url = //insert your url here
       var a = document.getElementsByTagName[](0);
       a.addEventListener("click", callAPI, false);

       function callAPI(){
           location.href=url;
       } 
   </script>
</head>
<body>
   <a href="#request">Click here to make HTTP call</a>
</body>
</html>

You click on that link, then redirect to that url where the XML/JSON is contained. This will show you the response that shows the raw data embedded onto HTML displayed on browser..

Let me know if this is what you're asking? Hope that helps..If you want to learn more about HTTP restful on javascript, you could try reading this article here.

Improve this answer

2 Comments

I think you've pretty much got the gits of what I'm asking. The problem with that is that whilst I can easily trigger the firing of any kind of AJAX call I want, using location.href=url to load the response is only ever going to make GET requests when loading the response.
In other words, the linked article shows how to fire the an AJAX request in response to a link or form submission, but doesn't demonstrate any way to load the response as a new page. (As opposed to transforming it into HTML and inserting it into the DOM.)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.