In the Chrome browser - Chrome developer tools - Network - I can show only POST requests by putting "method:POST" in the Filter search box.
What filter should I use in order to see both PATCH and POST requests?
The filter option is quite powerful, but it's limited to only using AND (conjunction). So simple workaround would be to use negatives...
For instance, in your case you could create a filter like this:
-method:GET -method:OPTIONS -method:PUT
This should filter out most of the requests. If you have other offending HTTP verbs you can easily add them.
Like me, I'm guessing many people came to this thread and don't necessarily need to filter to both POST and PATCH. That said, you can just use the filter like this to filter to POST requests:
On the Network Tab, in the filter box, type in:
method:POST
Unfortunately, you can't filter on multiple HTTP methods, or multiple pre-defined filters in general, such as using both method and domain.
You also can't mix a pre-defined filter and a normal text based one, as I discovered when answering How to filter by both text and property in Chrome DevTool's network panel?
You will have to filter one at a time, or alternatively if there's a lot of requests, you could export the HAR and filter based on the JSON output. I gave an example of parsing the JSON here if that helps.
Related
I'm using the springfox-boot-starter (3.0.0) with a REST controller that has two queries with endpoints distinguished only by request parameter e.g.
GET /foo?bar=y
GET /foo?nobar=x
I'm creating a Docket with DocumentationType.OAS_30 (or SWAGGER_2 - it doesn't seem to make any difference) and inspecting my API at the usual /swagger_ui URL.
Unless I add the "incubated" feature enableUrlTemplating(true) to my Docket I don't get to see both endpoints based on foo in the UI. I get one and only one of them.
But with that feature turned on, although I know see both endpoints, neither of them formulate the right URL when I exercise the endpoint; I get things like:
http://localhost:8080/foo{?bar%7D=&bar=111
which return a 404 because my controller presumably can't understand them.
I've found numerous discussions and issues on this, some of which mention use of an extra rfc6570 dependency to cure the problem, but the docs seem to indicate this is no longer supported, advising to turn enableUrlTemplating off.
Can someone advise me as to what is the correct approach to support for such endpoints?
I'm working in an app that makes many Ajax calls and results in a huge Network log in the Chrome inspector. I know that there are ways to query by things like mime-type, but I'm looking for a more fully-featured query capability.
For example, I'd like to be able to only see the pub/sub polling calls with a query like:
request_url:match(/pubnub.com/)
Or just see the GETs with:
request_method:GET
Is there a tool that makes queries like this possible?
You have a several options available. There are various pre-defined filter modes, as mentioned in the Network Analysis Reference (as you referenced in your question).
You can use the method filter with method:GET or method:POST in the input to only show requests of a particular method type. If you place a - beforehand, the filter will negate, e.g. -method:GET, will show all requests other than ones that are GETs.
There's also a filter type called domain, which is useful for only showing requests that match a particular domain. The options are limited though:
domain:stackoverflow.com would show all requests for the StackOverflow domain.
domain:*.google.co.uk would show all requests that are sub-domains
of Google UK.
Filtering request path (Method 1)
There's a better approach to filtering particular request paths. You can simply put pubnub.com in the filter input and it will match exactly what you put. You can also negate it with - beforehand, so entering -pubnub.com will show all requests that don't contain that in the path.
Filtering request path (Method 2)
You can also use Regex in the filter input, but not for the special filter modes (e.g. method, domain, etc.). So, in your case you could also use /pubnub.com/ as you filter. You can do more complex regular expressions, for instance, using /^((?!pubnub.com).)*$/ would do the equivalent of -pubnub.com via negative lookahead.
The reason I highlight Method 2 is because I fixed the feature a while ago in DevTools, as a result of another similar question that ended up being a bug in Method 1. Both bugs are completely fixed now though. See this for history of the problem if you're interested.
I recently discovered a nice little feature in the PAW app, that allows me to filter json in the response panel.
Unfortunately, it seems only to be able to select base on the key names. Is there some documentation somewhere that would explain the syntax of this filter (if any).
I was hoping actually, that it would be backed by something as powerful as jq's query language.
For the KeyPath in the filter you can see the example in the screenshot, it takes the format address.geocode.latitude for example (keys separated with dots).
We're having a bit of a discussion on the subject of posting data to a REST endpoint. Since the objects are quite complex, the easiest solution is to simply serialize them as JSON and send this in the request body.
Now the question is this: Is this kosher? Or should the JSON be set as a form parameter like data=[JSON]? Or is sending of JSON in the request body just frowned upon for forcing the clients using the application, to send their data via JavaScript instead of letting the browser package it up as application/x-www-form-urlencoded?
I know all three options work. But which are OK? Or at least recommended?
I'd say that both methods will work well
it's important that you stay consistent across your APIs. The option I would personally choose is simply sending the content as application/json.
POST doesn't force you to use application/x-www-form-urlencoded - it's simply something that's used a lot because it's what webbrowsers use.
There is nothing wrong about sending it directly as serialized JSON, for example google does this by default in it's volley library (which obviously is their recommended REST library for android).
If fact, there are plenty of questions on SO about how not to use JSON, but rather perform "normal" POST requests with volley. Which is a bit counter intuitive for beginners, having to overwrite it's base class' getParams() method.
But google having it's own REST library doing this by default, would be my indicator that it is OK.
You can use JSON as part of the request data as the OP had stated all three options work.
The OP needs to support JSON input as it had to support contain complex structural content. However, think of it this way... are you making a request to do something or are you just sending what is basically document data and you just happen to use the POST operation as the equivalent of create new entry.
That being the case, what you have is basically a resource endpoint with CRUDL semantics. Following up on that you're actually not limited to application/json but any type that the resource endpoint is supposed to handle.
For non-resource endpoints
I find that (specifically for JAX-RS) the application/x-www-urlencoded one is better.
Consistency with OAuth 2.0 and OpenID Connect, they use application/x-www-urlencoded.
Easier to annotate the individual fields using Swagger Annotations
Swagger provides more defaults.
Postman generates a nice form for you to fill out and makes things easier to test.
Examples of non-resource endpoints:
Authentication
Authorization
Simple Search (though I would use GET on this one)
Non-simple search where there are many criteria
Sending a message/document (though I would also consider multipart/form-data so I can pass meta data along with the content, but JAX-RS does not have a standard for this one Jersey and RestEasy have their own implementations)
I have a simple RESTful web service and I wish to test the PUT method on a certain resource. I would like to do it in the most simple way using as few additional tools as possible.
For instance, testing the GET method of a resource is the peak of simplicity - just going to the resource URL in the browser. I understand that it is impossible to reach the same level of simplicity when testing a PUT method.
The following two assumptions should ease the task:
The request body is a json string prepared beforehand. Meaning, whatever is the solution to my problem it does not have to compose a json string from the user input - the user input is the final json string.
The REST engine I use (OpenRasta) understands certain URL decorators, which tell it what is the desired HTTP method. Hence I can issue a POST request, which would be treated as a PUT request inside the REST engine. This means, regular html form can be used to test the PUT action.
However, I wish the user to be able to enter the URL of the resource to be PUT to, which makes the task more complicated, but eases the testing.
Thanks to all the good samaritans out there in advance.
P.S.
I have neither PHP nor PERL installed, but I do have python. However, staying within the realm of javascript seems to be the simplest approach, if possible. My OS is Windows, if that matters.
I'd suggest using the Poster add-on for Firefox. You can find it over here.
As well as providing a means to inspect HTTP requests coming from desktop and web applications, Fiddler allows you to create arbitrary HTTP requests (as well as resend ones that were previously sent by an application).
It is browser-agnostic.
I use the RESTClient firefox plugin (you can not use an URL for the message body but at least you can save your request) but also would recommend curl on the command line.
Maybe you should also have a look at this SO question.