I have to use Postman to send POST PUT and DELETE request to my server, is there any way I can hit POST request through browsers directly, using browser front end only
I Have a form that on submits should delete data from my server but using a form I can send only the GET or POST method only I know I can do it with the POST method, but I need to do it by DELETE.
You may be able to send a "DELETE" request via Ajax, the question should be will your server understand it.
While DELETE is a http method, it's not a generally supported request type in most back-end frameworks, rather you generally "overload" a POST request while setting the action as delete via a hidden form field.
So depending on your back-end framework, you would need to consult their documentation, but generally its accomplished as described above.
As for performing a POST request by URL alone, in a browser there is no way that I'm aware of, you need some tool, to be able to set headers to be able to form a POST request, such as JavaScript, curl etc
MDN has a great introduction to the topic
The HTTP POST method sends data to the server. The type of the body of the request is indicated by the Content-Type header.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/POST
Related
Let's say I have a model called User with its basic REST CRUD (GET, POST, DELETE, UPDATE).
When I go to user/4 (where 4 is an ID of a User that doesn't exist), there are two cases:
If I'm doing it with a REST client like Postman, I'd get a 404 and nothing else.
If I'm on the browser, I'll get a 404 page (with text, images, etc), which is defined in the views folder.
How can I achieve this for findOne, find, and other URLs? I want to be able to have JSON-only responses, and HTML pages responses for different types of requests. But I don't want to override the functions, because the ORM is already doing a lot of work that I don't want to lose.
EDIT: My solution would be to leave the API with a prefix, such as /api/user/4 and the HTML response without the prefix user/4, but I'd like to see more elegant solutions.
EDIT 2: I just decided to go all JSON, and use a REST service only with an independent front end ;)
If you have control over the headers sent by the API client, I see two clean semantic solutions, based on the headers sent :
you could rely on the X-Requested-With: XMLHttpRequest header to recognize Ajax queries
rely on a Accept: text/json header to explicitly request json
You could also modify the url with file extensions to request a specific response, user/4.html => send html, user/4 => send json.
I'm trying to work out my mobile data usage & I noticed there are simple APIs to query on https://secure.example.com/myaccountmgr/fapi/usage/data/... but they carry an Authorization: 0a60bd4e0blahlblahhash in order to query them.
I copied the curl commands when logging in, but it does a fairly complex redirection dance that I not sure how to get curl to compute since it's Javascript.
How do people do this? After further debugging I noticed that it later does a AJAX request via Angular to https://secure.example.com/myaccountmgr/fapi/login/esso where it returns a utoken which is used in the subsequent AJAX requests as the Authorization value. So what I am asking, is how do I view just this response once I log in, so I can grab the token?
I am trying to redirect to another URL from node js by using response.writeHead method
response.writeHead(301, {Location : <redirecturl>})
I need to have this redirection is being executed by POST method, however it is always executed by GET. What is the way that the redirection can be made as a POST request.
A redirect by default sends a GET request. According to the HTTP spec, a 301 redirection means sending a GET request. If you want to redirect with the same method (POST), you can try doing a 307 redirect instead.
There is no difference between redirection in both GET and POST methods. Both method should work find. Better you can your expressjs framework in which it is
res.redirect('http://example.com');
Be careful, when using status code 301 which means Moved Permanently. Once browser gets 301 status code, it will directly try the redirected URL from the next time.
Without seeing more of your code, I believe this is what you are describing:
The client has made a request to your application using an HTTP method (get, post, etc.) You are responding to that request by sending back a 301 error and a new URL (redirecturl)
The client then decides to implement a get request for the redirecturl.
You can't change how a client responds to a 301. That is out of your control and it is normal for browsers to initiate a get for the redirecturl.
You could initiate a post request from your server to the redirecturl.
You could send back a webpage which would then submit a post request from the client.
What are you trying to achieve?
I need to post some json data to external(another domain) API using ajax which on success should return me back some json data.
This API doesn't supports GET, only POST and I have no control on it, which means I can't do JSONP or enable CORS.
Any idea how to bypass the cross-domain limitations?
Post the data to your own server. Make the HTTP request to the API from your server. Relay the response.
You have to use a proxy page: you'll send the ajax post to the proxy page, which must reside on the same domain, and the proxy page will take care of posting the data to the final destination.
A php example: http://jquery-howto.blogspot.it/2009/04/cross-domain-ajax-querying-with-jquery.html
A Java example: http://snipplr.com/view/17987/
I know this is a long shot, but I figured I'd ask the question anyway.
I have an HTTPS page and am dynamically creating a form. I want to POST the form to an HTTP page. Is this possible without the browser popping up a warning? When I do this on IE8, I get the following message:
Do you want to view only the webpage content that was delivered securely?
Essentially, I'm asking about the inverse of question 1554237.
Sadly, I know of absolutely no way to not get warned when posting from HTTPS to HTTP. If you serve the form securely, the browser expects to submit the data securely as well. It would surprise the user if anything else was possible.
Nope, can't be done. Our good friend IE will always pop up that warning.
There is a way to do this if you write a back-end service of your own. So lets say you want to post an HTTP request to s1 using your front-end service fs1.
If you use Spring, you can use an ajax call from fs1 to a 'uri' that is recognized by your spring back-end, say bs1. Now, the service bs1 can make the call to the s1.
Pictorial representation here: http://i.stack.imgur.com/2lTxL.png
code:
$.ajax
({
type: "POST",
uri:/json/<methodName>
data: $('#Form').serialize(),
success: function(response)
{
//handle success here
},
error: function (errorResponse)
{
//handle failure here
}
})
You can solve this by either acting as a proxy for the form destination yourself (i.e. let the form submit to your server which in turn fires a normal HTTP request and returns the response), or to let access the page with the form by HTTP only.
If you don't need to actually redirect to the insecure page, you can provide a web service (authenticated) that fires off the request for you and returns the data.
For example:
From the authenticated page, you call doInsecure.action which you create as a web service over https. doInsecure.action then makes a manual POST request to the insecure page and outputs the response data.
You should be able to do this with the opensource project Forge, but it sounds like overkill. The Forge project provides a JavaScript interface (and XmlHttpRequest wrapper) that can do cross-domain requests. The underlying implementation uses Flash to enable cross-domain (including http <=> https) communication.
http://github.com/digitalbazaar/forge/blob/master/README
So you would load the Forge JavaScript and swf from your server over https and then do a Forge-based XmlHttpRequest over http to do the POST. This would save you from having to do any proxy work on the server, but again, it may be more work than just supporting the POST over https. Also, the assumption here is that there's nothing confidential in the form that is being posted.