I am using the same Authorization Header for all of my API requests. Instead of having to set an Environment Variable and individually adding it to each Request, I'd like to set it at the group level so it applies to all Requests within the group.
Does Paw currently offer this and if not, can we have this added to it's toolbox? Postman currently does this and it would be nice to have in Paw.
Related
I'm creating a group of queries that will all share the exact same set of headers.
Is it possible to create the group of headers once and then copy/paste them to other queries? Or, even better, can I assign a known group of headers to multiple queries?
The best way to do so is to have an environment domain for that. Make one variable per header, you may have a variable called Content-Type (as an example) and give it the application/json value for one environment, or application/xml for another environment. This way you'll be able to switch between JSON and XML in many requests at once.
In the example above, there are 2 variables set, one for the Content-Type and another one for Accept. Both variable are then used in the request. As you can see in the preview at the bottom, the variables are replaced by their values in the HTTP request.
Old question, but still relevant. The answer still appears to be no, and hopefully #Micha Mazaheri still intends to implement it.
As an alternative, I create a Group called "_templates", then I'll have one request for logical request type. For example I will have a request with Auth headers set, or one for simple guest routes.
When it comes time for a new request, I simply right click and duplicate.
I am trying to implement a system which depends on the HTTP get/post parameter order.
I want the system provide a remote function call mechanism, for example:
Suppose there is a function foo(int, int), it can be called remotely by HTTP get http://ip:port/method=foo¶mType=int¶m=1¶mType=int¶m=2 or HTTP post with post data as method=foo¶mType=int¶m=1¶mType=int¶m=2, which acts as call foo(1,2) locally.
As you see, it depends on parameter order extremely. If parameter order goes wrong, foo(2,1) will be called unexpected.
But I am not sure is it reliable, since I think W3 did not make a spec for the parameter order(tell me if I'm wrong).
I am not sure the parameter order will be as expected at three points:
Will the client(such as a browser or jmeter) post the parameter in
order as you see?
Will the order be preserved during transmission?
Will the web contain(such as tomcat) or the web framework(such as django)
preserve the parameter order?
I did a few tests, found chrome, firefox and jmeter will send get/post parameter as expected and tomcat preserved the parameter order, but it's a hard work to find negetive cases and I am not sure there is no such cases. So I can't be sure is the system I am trying to implement is reliable.
Does anyone have any experiences for such problem? All suggestions are welcome.
You cannot enforce parameter order in either a URL query string or application/x-www-form-urlencoded post. Although W3C defines HTML to transmit form values in the order they appear in the HTML, server-side scripts are free to access parameters by name in any order, and having multiple parameters with the same name is a recipe for disaster. You need to rename your parameters to make them unique and order-independant, eg:
method=foo¶m1Type=int¶m1=1¶m2Type=int¶m2=2
This way, foo() can read its 2 paramX parameters regardless of their ordering. For instance, this would also be perfectly valid and still be functional:
param2=2¶m1=1¶m1Type=int¶m2Type=int&method=foo
Personally, I would suggest you eliminate the paramType parameters:
method=foo¶m1=1¶m2=2
Your API spec dictates the data types of the parameters. If a client sends a non-integer value to foo(), return an HTTP error, like 400 Bad Request. Always validate input before using it.
If the order matters I would design it in a way like #TGH said where the parameters are part of the path like http://someServer/param1/param2. This enforces ordering and wont allow requests to be made any other way. If you design it using query parameters expecting the browser to maintain the order, that opens up the possibility for a security hole for someone to take advantage of.
Can we use Filter instead of Servlet? Can filter (without using servlet) be able to serve incoming request?
Filters are used to modify the header and/or content of a request or response. I have never seen them used to create the response itself and I don't think they can be used for that, since they need to be "chained" with an actual resource. From the Java EE 6 tutorial:
A filter is an object that can transform the header and content (or
both) of a request or response. Filters differ from web components in
that filters usually do not themselves create a response. Instead, a
filter provides functionality that can be “attached” to any kind of
web resource.
Filters have a wide array of uses; the Servlet 2.3 specification suggests the following uses:
authentication filters
logging and auditing filters
image conversion filters
data compression filters
encryption filters
tokenizing filters
filters that trigger resource access events
XSL/T filters that transform XML content
MIME-type chain filters
Use a Filter when you want to filter and/or modify requests based on specific conditions.
Use a Servlet when you want to control, preprocess and/or postprocess requests.
Filter are best suited for authorization, because it can be configured to run for all pages of a site. So you only need one filter to protect all your pages.
Useful Links:
filter tutorial
filter in detail
referred answer
In a current project the UI posts an ordered list of ids of several files under one key to tell the server in which order the files need to be processed:
file[]=18&file[]=20&...
So far the order is preserved when handing this over from client to server, however I could find no specification whether the HTTP protocol keeps the parameters in the specified order. So the question is, is it safe to depend on the given order, or should I implement a workaround to assign each file id a specific order? E.g.
file_18=0&file_20=1&...
Edit:
jQuery Ui has a serialize method, that will pass the parameters just in the initial way that I described above:
foo_1, foo_5, foo_2 will serialize to foo[]=1&foo[]=5&foo[]=2
This is for a sortable list, so I assume they know what they are doing.
Depends on the server. In general, the order is guaranteed by the TCP protocol. If you can read in this order, your HTTP parser stores the parameters in the direct sequence - do not worry. Nobody will be changing these parameters in some places.
HTTP doesn't specify the format of GET and POST data. So they just get passed as blobs of data.
It is up to your form data parser to maintain the order (I'm not aware of any that don't (for identically named fields).
This question already has answers here:
When should I use GET or POST method? What's the difference between them?
(15 answers)
Closed 9 years ago.
I've only recently been getting involved with PHP/AJAX/jQuery and it seems to me that an important part of these technologies is that of POST and GET.
First, what is the difference between POST and GET? Through experimenting, I know that GET appends the returning variables and their values to the URL string
website.example/directory/index.php?name=YourName&bday=YourBday
but POST doesn't.
So, is this the only difference or are there specific rules or conventions for using one or the other?
Second, I've also seen POST and GET outside of PHP: also in AJAX and jQuery. How do POST and GET differ between these 3? Are they the same idea, same functionality, just utilized differently?
GET and POST are two different types of HTTP requests.
According to Wikipedia:
GET requests a representation of the specified resource. Note that GET should not be used for operations that cause side-effects, such as using it for taking actions in web applications. One reason for this is that GET may be used arbitrarily by robots or crawlers, which should not need to consider the side effects that a request should cause.
and
POST submits data to be processed (e.g., from an HTML form) to the identified resource. The data is included in the body of the request. This may result in the creation of a new resource or the updates of existing resources or both.
So essentially GET is used to retrieve remote data, and POST is used to insert/update remote data.
HTTP/1.1 specification (RFC 2616) section 9 Method Definitions contains more information on GET and POST as well as the other HTTP methods, if you are interested.
In addition to explaining the intended uses of each method, the spec also provides at least one practical reason for why GET should only be used to retrieve data:
Authors of services which use the HTTP protocol SHOULD NOT use GET based forms for the submission of sensitive data, because this will cause this data to be encoded in the Request-URI. Many existing servers, proxies, and user agents will log the request URI in some place where it might be visible to third parties. Servers can use POST-based form submission instead
Finally, an important consideration when using GET for AJAX requests is that some browsers - IE in particular - will cache the results of a GET request. So if you, for example, poll using the same GET request you will always get back the same results, even if the data you are querying is being updated server-side. One way to alleviate this problem is to make the URL unique for each request by appending a timestamp.
A POST, unlike a GET, typically has relevant information in the body of the request. (A GET should not have a body, so aside from cookies, the only place to pass info is in the URL.) Besides keeping the URL relatively cleaner, POST also lets you send much more information (as URLs are limited in length, for all practical purposes), and lets you send just about any type of data (file upload forms, for example, can't use GET -- they have to use POST plus a special content type/encoding).
Aside from that, a POST connotes that the request will change something, and shouldn't be redone willy-nilly. That's why you sometimes see your browser asking you if you want to resubmit form data when you hit the "back" button.
GET, on the other hand, should be idempotent -- meaning you could do it a million times and the server will do the same thing (and show basically the same result) each and every time.
Whilst not a description of the differences, below are a couple of things to think about when choosing the correct method.
GET requests can get cached by the browser which can be a problem (or benefit) when using ajax.
GET requests expose parameters to users (POST does as well but they are less visible).
POST can pass much more information to the server and can be of almost any length.
POST and GET are two HTTP request methods. GET is usually intended to retrieve some data, and is expected to be idempotent (repeating the query does not have any side-effects) and can only send limited amounts of parameter data to the server. GET requests are often cached by default by some browsers if you are not careful.
POST is intended for changing the server state. It carries more data, and repeating the query is allowed (and often expected) to have side-effects such as creating two messages instead of one.
If you are working RESTfully, GET should be used for requests where you are only getting data, and POST should be used for requests where you are making something happen.
Some examples:
GET the page showing a particular SO question
POST a comment
Send a POST request by clicking the "Add to cart" button.
With POST you can also do multipart mime encoding which means you can attach files as well. Also if you are using post variables across navigation of pages, the user will get a warning asking if they want to resubmit the post parameter. Typically they look the same in an HTTP request, but you should just stick to POST if you need to "POST" something TO a server and "GET" if you need to GET something FROM a server as that's the way they were intended.
The only "big" difference between POST & GET (when using them with AJAX) is since GET is URL provided, they are limited in ther length (since URL arent infinite in length).