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.
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?
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.
Some sites use hyper links like:
www.example.com\index.php?x=test.php
www.example.com\index.php?test.php
www.example.com\index.php?\test.php
instead of simply:
www.example.com\test.php
Are there any advantages of linking to other pages using query strings instead of simple hyperlinks.
When to use them
If the order is irrelevant or if they can be combined in different ways. In many cases like pagination not all query strings are needed to get the desired result. So the are usually always optional.
Advantages
They do not have the encoding issues of named params and are pretty much the way all other web apps also use such volatile params. So it is the de facto standard for web apps.
With query strings the short-routed action names (usually all index actions) don’t pop up anymore as long as you don’t use passed params:
URLs are passed in Referrer headers – if a secure page uses resources, such as javascript, images or analytics services, the URL is passed in the Referrer request header of each embedded request. Sometimes the query string parameters may be delivered to and stored by third party sites.
It can be useful wile posting a data on a webservice, or u can even pass a session ID along with the URL in query parameters provided they are encoded.
The type of notation that you mentioned earlier is aided by the concept called url rewriting.
Many php frameworks these days use MVC architecture for code organisation into three tiers. This enhance code scalability and web application's security.
All the requests to the server are directed to index.php where they are resolved to load a particular action, thus hiding the background layout of the code.
Here test.php can be present either at the root or inside some other folder depending upon the location specified to the routing algorithms that are called in index.php
A REST API can have arguments in several places:
In the request body - As part of a json body, or other MIME type
In the query string - e.g. /api/resource?p1=v1&p2=v2
As part of the URL-path - e.g. /api/resource/v1/v2
What are the best practices and considerations of choosing between 1 and 2 above?
2 vs 3 is covered here.
What are the best practices and considerations of choosing between 1
and 2 above?
Usually the content body is used for the data that is to be uploaded/downloaded to/from the server and the query parameters are used to specify the exact data requested. For example when you upload a file you specify the name, mime type, etc. in the body but when you fetch list of files you can use the query parameters to filter the list by some property of the files. In general, the query parameters are property of the query not the data.
Of course this is not a strict rule - you can implement it in whatever way you find more appropriate/working for you.
You might also want to check the wikipedia article about query string, especially the first two paragraphs.
I'll assume you are talking about POST/PUT requests. Semantically the request body should contain the data you are posting or patching.
The query string, as part of the URL (a URI), it's there to identify which resource you are posting or patching.
You asked for a best practices, following semantics are mine. Of course using your rules of thumb should work, specially if the web framework you use abstract this into parameters.
You most know:
Some web servers have limits on the length of the URI.
You can send parameters inside the request body with CURL.
Where you send the data shouldn't have effect on debugging.
The following are my rules of thumb...
When to use the body:
When the arguments don't have a flat key:value structure
If the values are not human readable, such as serialized binary data
When you have a very large number of arguments
When to use the query string:
When the arguments are such that you want to see them while debugging
When you want to be able to call them manually while developing the code e.g. with curl
When arguments are common across many web services
When you're already sending a different content-type such as application/octet-stream
Notice you can mix and match - put the the common ones, the ones that should be debugable in the query string, and throw all the rest in the json.
The reasoning I've always used is that because POST, PUT, and PATCH presumably have payloads containing information that customers might consider proprietary, the best practice is to put all payloads for those methods in the request body, and not in the URL parms, because it's very likely that somewhere, somehow, URL text is being logged by your web server and you don't want customer data getting splattered as plain text into your log filesystem.
That potential exposure via the URL isn't an issue for GET or DELETE or any of the other REST operations.
I'm attempting to move an existing (and working) client-side jQuery validation schema to JSONSchema to allow myself to validate arbitrary JSON on both the client and server.
My application is essentially a bunch of gigantic forms with lots of complex logic determining which questions should be asked based on the user's response to other questions. The forms each have over 200 fields.
Right now I'm only doing client-side validation and that works well about 99% of the time. Browser issues have cropped up on a few occasions, but nothing catastrophic. That being said, I want to do server-side validation (!).
After reading the JSONSchema draft and browsing around some of the v3 implementations, it seems like I might lose some of the more complex rules that my application has come to depend upon. I want to be sure that I'm not missing something before moving too far in any direction.
Some examples:
"If x == 10, then y is required, otherwise it's optional"
10 could be a literal value, an enum, etc., but I need to be able to reference another field in the same structure and guarantee it's value not only exists, but is equivalent to a specific type / value.
I think this is addressed in this thread on the JSONSchema list.
"If x = today's date, and y = tomorrow's date, then x > y"
This logic will be used to ensure that the "from" date comes before the "to" date.
From what I can see there's nothing like this and the only way I can see doing it is passing in a freshly eval-ed chunk of JSON as the schema.
The closest thing I've found to meet the above needs is CERNY.
If I'm barking up the wrong tree, please let me know. I'm also looked into running backbone.js on both the client and server.
tl;dr;
I want to maintain one set of validation rules for large and complex forms and apply these validation rules to arbitrary JSON documents on both the client and server side.
there is many tricks but not all of them are possible. For example
if x == 10 then y is required can be achieved with something like (draft 3):
"type":[
{"properties":{"x":{"enum":[10]}, "y":{"required":true}}},
{"properties":{"x":{"disallow":[{"enum":[10]}]}}}
]
Let's say, it's possible but very tricky… a schema is basically supposed to validate the structure, not it's content (even if there is few properties for this)
Another possible way I personally do like is to "extend" the current validation graph with an external url based schema. The idea is to send parameters of the current document on an url which one will return a relevant schema according to those parameters.
Example:
{
"extends":{"$ref":"http://checkCustomValidity/{x}/{y}/"};
}
Where at "runtime" the schema sent back could be a {"disallow":"any"} if not allowed or {} if ok
This is useful as the url can be both used for the client and server side (your client will not be completely standalone but in some cases, you just cannot)
A real life usage for this is in cases where it is obliged to use a remote service. For example if I do have to check if my nickname is already used on the server during the registration. I code a server side web service answering to the request path: http://www.server.com/isNicknameUsed/{nickname}