I have been developing crossrider extension. I need to obtain data about users requests and then analyse them. For that, I used appAPI.webRequest.monitor.onRequest method.
However I am not able to obtain some information that I would really need:
If request is POST, I am not able to get post parameters (data)
I am not able to get response headers and response text
#Shlomo already proposed solution to use appAPI.request method to obtain response text and headers, but you can not do that for post requests if you dont have post parameters (data). Also that way, every request is made twice, which is not desired.
Related
Is it recommended to send a JSON body via a POST HTTP Request which doesn't modify anything?
Based on the link below, a Get request is not recommended to have a body. Thus, the other way is the one above.
HTTP GET with request body
Example:
Get the list of users, or anything for that matter based on parameters.
Http GET example.com/users
Body
{
name:"John",
age:1,
... long list of parameters
}
Is it recommended to send a JSON body via a POST HTTP Request which doesn't modify anything?
The rule is that POST is the default; it should be used unless there is something better.
For a request with "effectively read only" semantics, you want to use GET instead of POST... if it works. The challenge can be those cases where the request-target (aka: the URI) gets long enough that you start running into 414 URI Too Long responses. If your identifier is long enough that general purpose components refuse to pass the request along, then it is not something better, and you fall back to POST.
An origin server SHOULD NOT rely on private agreements to receive content, since participants in HTTP communication are often unaware of intermediaries along the request chain. (HTTP Semantics, 9.3.1)
In other words, introducing a private agreement to include content in a GET request trades away inter-op, which - if you want "web scale" - is not a winning trade. So GET-with-a-body is not better, and you fall back to POST.
The HTTP working group has been working on semantics for a new "effectively-read-only-with-a-body" method token, which could prove to be an alternative for requests where you need to include a bunch of information in the body because it is too long to encode it into the URI. But we don't have a standard for that today, which means that it is not something better, and you fall back to POST.
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.
GET is used to retrieve remote data, and POST is used to insert/update remote data
But when we use <form> to send data we can put in action either POST or GET and in both cases data will be sent. In this case data will not be retrieved or inserted just will be sent to the server.
Do these GET and POST methods in the <form> are not the same as GET and POST from the description above?
The form action will tell your browser how to send the form data.
In case of GEt the form data will be present as query string arguments, in case of POST as a multipart/form-data body. And, of course, this will also alter the method of the query (as GET or POST).
This is for the client part of the protocol.
Now, on the server side, GET and POST SHOULD not behave in the same way.
GET is indempotent
POST is not
It means the server (or the server chain, you could have a Reverse Proxy Cache in the chain) MUST expect that a POST is doing something to the application data, so the application or state is not the same after the POST (maybe you now have a session, or you've just deleted something, or added something). End this means you cannot re-play a POST two times without risks. In fact nobody should never replay the POST, that's one action.
If your form is posted as a GET that's a diffrent story. Your just asking for an url (wich contains your form data in the query string of the url), and you get a result, but replaying the same url several times SHOULD NOT be a problem, we could also cache the result and reuse this cached result for someone requesting the same url (so having the same elements in the form, which are now in the url).
So your application MUST NOT perform data alteration if the method is GET. Not deleting something, not creating something, etc.
So why would you send a form as GET? Maybe just to obtain a filtered page result where everybody should obtain the same page result with the same filters. But certainly not to post a registration form (or an admin-level-delete-this-user action).
We found ourselves in a dead end when trying to follow standards as we need to build a request that should be a GET and should have a meaning Body.
The request just wants to retrieve some data, no modification inside the database, just getting some data. But at the same time we need to send an array of ids for the objects we want to retrieve, and no, these objects can't be indexed in any way so we really need to send the list of ids or alternatively make 100 requests to the server to get them one by one. That's not gonna happen.
We could also add the list to the URL, but we can't be sure the URL won't end up being too long if the list of ids were to be too big. So to ensure the system doesn't fail we want to use the Body.
I read that a GET can have a Body, but only if it isn't meaningful:
HTTP GET with request body
Yes. In other words, any HTTP request message is allowed to contain a message body, and thus must parse messages with that in
mind. Server semantics for GET, however, are restricted such that a
body, if any, has no semantic meaning to the request. The requirements
on parsing are separate from the requirements on method semantics.
So, yes, you can send a body with GET, and no, it is never useful to do so.
This is part of the layered design of HTTP/1.1 that will become clear again once the spec is partitioned (work in progress).
....Roy
But our Body IS meaningful, which takes us to have to decide between unfollowing HTTP standards or unfollowing REST standards.
Is there any alternative to that? (It's not that this blocks us but I would like to know the answer).
Thank you very much.
you should consider changing your request to POST method.
As I understand it, there are three potential issues with a GET with request body: (link to blog)
Not all servers will support this.
Not all tools will support this (Swagger, POSTMAN added support this year: https://github.com/postmanlabs/postman-app-support/issues/131)
There is not yet a consensus on GET with request body. (For example, is Dropbox still using a POST)
so you'll have problems process the body with GET
I use fiddler core to intercept the request and provide a response to it. I know its possible to use saz files to save the response. But the problem is that I need to be able to customize the response. While its a saz file I cant customize the response manually.
Is there a way to save response caught by fiddler to a text file in json like format, so that I could edit it and could serve it as response to any request using fiddler core? For now i see I can save response as a plain text. But how do I load this request to fiddler or parse it with fiddler core to populate all the response properties? Is there some format I could use, that will allow me to manually edit the response?
UPDATE
I see I can just open saz archive, make my edits to reponse and use it to specify the response. Thats exactly what I was looking for. Also there is a way to save response session as har file. Is it possible to save one single response as har/saz file? Currently I can only save session and it contain all requests and responses. Is there a way to limit saved data to 1 request and 1 response?
You have a SAZ file, which contains the full content of a response. Your code may load the SAZ File into FiddlerCore using the Utilities.ReadSessionArchive method. You will then have an array of Session objects.
As FiddlerCore receives requests, you can evaluate whether or not you wish to reply to each request using a previously-loaded response or whether you want to instead let the request flow through to the server. To let the request flow through to the server, do nothing.
To return a previously-generated response, in FiddlerCore 2.4.6.4+ (not yet released), simply call utilAssignResponse on the new Session. For earlier versions of FiddlerCore without this new method, your OnBeforeRequest method should call a method that looks something like this:
public void utilAssignResponse(Session oS, HTTPResponseHeaders oRH, byte[] arrBody)
oS.utilCreateResponseAndBypassServer();
oS.oResponse.headers = (HTTPResponseHeaders)oRH.Clone();
oS.responseBodyBytes = arrBody ?? Utilities.emptyByteArray;
oS.oFlags["x-Fiddler-Generated"] = "Generated by myCode";
}