I want to capture how parameters are being sent. Usually what I do is to make a request and check on Firebug's params tab what are the parameters sent. However, when I try to do this on the following site (http://www.infraero.gov.br/voos/index_2.aspx), it doesn't work - I can't see what are the parameters in order to repeat this request using curl. How can I get it? I'm not sure but I think that cookies are being used.
EDIT
I was able to get the request content, but couldn't understand it. It seems it uses javascript to generate the proper request. How can I reproduce this request via cURL?
Did you see this previous question cURL post data to asp.net page ? That might answer the question right there (all I did was search "ASP.NET cURL"). And this one: Unable to load ASP.NET page using Python urllib2 talks about Python, but it approaches it in a way that should translate to cURL.
But for my $0.02, I wouldn't bother trying to untangle ASP.NET's and __VIEWSTATE and javascript. Is it an absolute requirement that you use cURL?
I think you would be better off using a client that works more like a real browser and understands javascript. That's a bit of work, but it isn't as bad as it sounds. I've done this before with http://watirwebdriver.com/ and a short Ruby script. Here's how to do it with Python and Mechanize (this is probably a bit more lightweight).
http://phantomjs.org/ is another option that you script using javascript. If you Google "Scraping ASP.NET" you will see that this is a common problem.
You didn't say how you want it done, but you can send the request with curl simply with curl -d name1=contents1&name2=contents2 [TARGETURL] etc.
Note that you probably first need to fetch the main page and extract the "__VIEWSTATE" form field and submit back that (VERY huge) contents to get your submission accepted.
Related
I wanted to use vs code's extension REST client for testing purposes. So I used a curl of an existing API running on my local machine. But instead of JSON, I got HTML as a response. The curl works as expected in the terminal but not with the extension.
The same Behaviour is with another extension named Thunder Client.
Postman is getting JSON responses for the same API I believe that issue lies within vs code itself, I just don't know how to resolve it.
According to this article:
https://softwareengineering.stackexchange.com/questions/207835/is-it-ok-to-return-html-from-a-json-api
If you have declared you only accept one format in the header then the service should only send back that format or throw an error. If you have not put an ACCEPT in the header, the the service may send back whatever.
Check what is in the ACCEPT header:
But also check how Thunder Client translates the call in powershell:
I see that in my call the response is translated to JSON. I would guess that most REST clients are assuming that users want to work in JSON. Maybe that's what your two REST clients are doing?
I'm very new to API testing.
I'm trying to make use of Google Chrome's developer tools to understand and explore this subject.
Question 1:
Is it possible to get the response (possibly in JSON format) of a simple GET request using chrome developer tools?
What I'm currently doing is:
Open chrome developer tools
Go to Network tab
Clear existing logs
Send a post request simply by hitting a URL. e.g. https://stackoverflow.com/questions/ask
Check the corresponding docs loaded
Question 2:
What are the relevance "Reponse Headers" shown on the image above? I mean, am I correct to think that this is the response I am getting after doing the GET request?
Any help or references you can give are much appreciated!
If you want to test a rest api I sugest you get postman which is meant for that purpose.
Going to your questions:
Question 1: Is it possible to get the response (possibly in JSON
format) of a simple GET request using chrome developer tools?
The first point to make clear is that it is the server who will or will not send a json response to the browser. Not the browser who can choose to see any response as json.
If you send a GET request that the server responds with a json object or json array and the Content-type header is set to application/json, you will see that response already formated in the main window of the browser.
If the Content-type is set to text/html, for example, then you will still get the a json text as response in the main window but it won't be nicely formated. Depending on how the response was sent, sometimes you can see it nicely formatted by left clicking the browser window and selecting view source page.
For this you don't need developer's tools unless you want to see how long did it take to receive the response, or check the headers for some specific value, etc, but nothing to do with receiving the response or rendering it on screen.
Developer's tools is more usefull if you are working with javascript/jquery and/or if you are sending ajax requests (GET or POST). In these cases you can debug the function and also see the ajax request to check what actually went out from your browser and what was received as a response.
Question 2: What are the relevance "Reponse Headers" shown on the
image above? I mean, am I correct to think that this is the response I
am getting after doing the GET request?
In the response you get the two things, the headers, and the content. The json objects you see are part of the content not the headers.
The headers will tell the browser, for example, that the body is json (vs. an html documenet or something different), besides of other information like cache-control, or how long the body is.
Search for http headers for more information on which are teh standard headers.
To answer your questions narrowly:
Is it possible to get the response (possibly in JSON format) of a simple GET request using chrome developer tools?
Yes! Just click the Response tab, which is to the right of the Headers tab that's open in your screenshot.
What are the relevance "Reponse Headers" shown on the image above? I mean, am I correct to think that this is the response I am getting after doing the GET request?
Yes, these are the HTTP headers that were sent with the response to your request.
The broader question here is "how do I test a REST API?" DevTools is good for manual testing, but there are automated tools that can make it more efficient. I'll leave that up to you to learn more about that broad topic.
We are working on a time critical task and are required to write performance script for a REST WS using jMeter.
The REST API takes an auth header. This auth header has:
A signed URL (of the REST API itself).
A hash of everything sent in POST body.
We want a jMeter script so that it can:
Read the contents of the POST body from say an excel sheet or from a java method etc. as the content of post body has to change per login.
Create the hash of POST body everytime the content of body changes and use this hash in the auth header.
Sign the URL and use it in auth header.
My questions are:
Is all the above possible to achieve? This is the minimum i want to know so that I know if I have to spend any more time on this.
What is the best way to do this?
I am assuming that the content of POST body and auth header both can be dynamic. Is this correct? If not, we cannot write this script at all.
The only jMeter i know is what is here in the comment. It would be impossible to get all my answers in the given time.
Any answers, help, pointers would be helpful.
Appreciate you reading this - thanks in advance.
Yes, possible. We have done similar things.
Two possible options are:
use a beanshell pre-processor
use a custom function
We opted for the latter as it used memory better
and 3. Yes, you can pass in vars to make each request different. One way to source data is using a CSV Data Config control.
I'm using the ASIHTTPRequest lib in my iOS app for making REST requests to a web app. I'm doing my best to use the correct verbs (GET, POST, PUT, DELETE) when making the various requests, but when making a POST request, I'm not sure I understand why it matters if I include the parameters in the POST request or in the URL. It works both ways, so why should I include the parameters in the POST request instead of just including them in the URL? As I understand it, the only reason for include the parameters in a POST request is to keep them from being visible in the URL in case someone is looking over your shoulder, or something like that. But if I'm making a POST request from my iOS app and there's no browser involved, then does it really matter which way I do it?
Thanks so much for your wisdom, I'm still learning!
When using a POST request, it is good practice to put the parameters in the data instead of the URL. In your case, it works to put it in the URL, but this isn't always true. Some scripts will expect the parameters to be in a specific place and not find them if they aren't there. As for what POST is good for, it allows you to send more data. The URL is limited to a length of 255 characters, so you need to use some other method if you want to send more data than that. The data in a POST request also doesn't need to be encoded to be compatible with the URL specification.
As I understand it, the only reason for include the parameters in a POST request is to keep them from being visible in the URL in case someone is looking over your shoulder, or something like that.
You misunderstand it.
There are other issues. If your site makes changes to data based off a GET request, it's possible that spambots, search engines, browser prefetchers, and other automated tools will trigger potentially destructive data changes.
If the endpoint isn't under your control, it's entirely possible that it won't even accept the parameters as GET parameters. Most APIs require proper usage of the GET vs. POST verbs.
I want to launch fiddler from the command line and populate the request builder with given request parameters.
Is this possible using ExecAction (or otherwise) and FiddlerScript?
Can someone get me started with the necessary FiddlerScript needed? I can't find anything in the docs...
Thanks
FiddlerScript can generate any HTTP request you want. Look at http://fiddlerbook.com/Fiddler/dev/ScriptSamples.asp and particularly the use of the utilIssueRequest method.
Sending a new request to the Composer requires that you call FiddlerApplication.DoComposeByCloning(oS), passing the Session to display in the Composer as the parameter.