The swagger 2 GUI Response Headers view does not seem to display the received headers in the order they appear on thw wire, but instead in a random order.
I have a number of headers (added by jersey) of the form X-Jersey-Tracing-00x, these appear on the wire in sequence
curl -v gives me the headers in the correct order.
Is this a know bug ?
There is no defined order for HTTP Response headers, except for the status line (which should always be first). So the term 'correct order' is inapplicable to headers in this particular case. I guess that since Swagger first puts the header lines in a JS object, does a little bit of processing and only then lists them, the ordering might be different than cURL's.
If I had to guess, I'd say they won't make Swagger compatible to cURL's output, as the order is not important in the first place.
Related
I am just trying to set the labels of a GitLab merge request.
When I make this PUT request to GitLab
requests.put( https://gitlab.com/api/v4/projects/{}/merge_requests/{}".format(project_id, mr_num), {"labels":mr_new_labels}, headers={'PRIVATE-TOKEN': os.getenv("GITLAB_ACCESS_TOKEN", "")} ),
it will work if mr_new_labels is any string or a list with 1 element - so if the request is just setting 1 label (or 0 labels, with an empty string).
Howevever, if mr_new_labels is a list with multiple elements, only the last element will be 'put' (perhaps the elements in the list are 'put' in turn and replace each other, rather than the list being put at once), so the merge request will only have 1 label.
I have tried using a POST request to do this instead, but for me a POST request with the same syntax as the PUT request, with any string or list value of mr_new_labels, ie
requests.post( https://gitlab.com/api/v4/projects/{}/merge_requests/{}".format(project_id, mr_num), {"labels":mr_new_labels}, headers={'PRIVATE-TOKEN': os.getenv("GITLAB_ACCESS_TOKEN", "")} ), doesn't throw an error but doesn't work at all, even though wherever I have looked I have not seen any difference between the syntax of a PUT request and a POST request. So I thought that it might be to do with the GitLab API not accepting POST requests. (Should POST requests be written differently to PUT requests?)
So, I have no idea how I could possibly set 'labels' as a list with multiple values (which I know that it can be), either using PUT or POST requests. Any ideas would be much appreciated :)
Cheers,
Milan
You can't PUT (or POST) a list value (as a HTTP query is just a string). However, {"labels":",".join(mr_new_labels)} will work :)
I need to reuse value which is generated for my previous request.
For example, at first request, I make a POST to the URL /api/products/{UUID} and get HTTP response with code 201 (Created) with an empty body.
And at second request I want to get that product by request GET /api/products/{UUID}, where UUID should be from the first request.
So, the question is how to store that UUID between requests and reuse it?
You can use the Request Sent Dynamic values https://paw.cloud/extensions?extension_type=dynamic_value&q=request+send these will get the value used last time you sent a requst for a given request.
In your case you will want to combine the URLSentValue with the RegExMatch (https://paw.cloud/extensions/RegExMatch) to first get the url as it was last sent for a request and then extract the UUID from the url.
e.g
REQUEST A)
REQUEST B)
The problem is in your first requests answer. Just dont return "[...] an empty body."
If you are talking about a REST design, you will return the UUID in the first request and the client will use it in his second call: GET /api/products/{UUID}
The basic idea behind REST is, that the server doesn't store any informations about previous requests and is "stateless".
I would also adjust your first query. In general the server should generate the UUID and return it (maybe you have reasons to break that, then please excuse me). Your server has (at least sometimes) a better random generator and you can avoid conflicts. So you would usually design it like this:
CLIENT: POST /api/products/ -> Server returns: 201 {product_id: UUID(1234...)}
Client: GET /api/products/{UUID} -> Server returns: 200 {product_detail1: ..., product_detail2: ...}
If your client "loses" the informations and you want him to be later able to get his products, you would usually implement an API endpoint like this:
Client: GET /api/products/ -> Server returns: 200 [{id:UUID(1234...), title:...}, {id:UUID(5678...),, title:...}]
Given something like this, presuming the {UUID} is your replacement "variable":
It is probably so simple it escaped you. All you need to do is create a text file, say UUID.txt:
(with sample data say "12345678U910" as text in the file)
Then all you need to do is replace the {UUID} in the URL with a dynamic token for a file. Delete the {UUID} portion, then right click in the URL line where it was and select
Add Dynamic Value -> File -> File Content :
You will get a drag-n-drop reception widget:
Either press the "Choose File..." or drop the file into the receiver widget:
Don't worry that the dynamic variable token (blue thing in URL) doesn't change yet... Then click elsewhere to let the drop receiver go away and you will have exactly what you want, a variable you can use across URLs or anywhere else for that matter (header fields, form fields, body, etc):
Paw is a great tool that goes asymptotic to awesome when you explore the dynamic value capability. The most powerful yet I have found is the regular expression parsing that can parse raw reply HTML and capture anything you want for the next request... For example, if you UUID came from some user input and was ingested into the server, then returned in a html reply, you could capture that from the reply HTML and re-inject it to the URL, or any field or even add it to the cookies using the Dynamic Value capabilities of Paw.
#chickahoona's answer touches on the more normal way of doing it, with the first request posting to an endpoint without a UUID and the server returning it. With that in place then you can use the RegExpMatch extension to extract the value from the servers's response and use it in subsequent requests.
Alternately, if you must generate the UUID on the client side, then again the RegExpMatch extension can help, simply choose the create request's url for the source and provide a regexp that will strip the UUID off the end of it, such as /([^/]+)$.
A third option I'll throw out to you, put the UUID in an environment variable and just have all of your requests reference it from there.
I have two requests in Paw -
The first is GET request authorization/login that returns a dynamic value in the Raw body.
The second is a POST that uses the first request's raw body dynamic value as a header value.
The code generator (using HTTPie) does not account for the dynamic changing value in the second request- How do I resolve this issue?
How can I solve this issue?
Simply put, the workflow requires a total of two requests for each time I want to run it. (1 Authorization and 1 for Data) I wanted to run the entire workflow as two separate shell scripts using HTTPie
The documentation for Response Parsed Body Dynamic Value doesn't make much sense to me. I r-clicked on the JSON response element as described, in this case, userid
{"authorization":"T98J_J8QcH5lC83TOKZxaWB","userid":"T98J_J8QcH5lC83TOKZxaWB","lastLogin":"2014-12-15 15:17"}
but did not receive the menu option to Copy as Dynamic Value as stated. I got the standard text editor context menu. So, either I'm misreading the doc, or it's incorrect. Here's what I want to do: Take the dynamic value for the userid and pass it as part of the URL (not a parameter) to subsequent calls. Is this possible with Paw?
Here's how you can do it manually.
Right click on the field where you want to reuse the value. In the contextual menu, pick Response > Response Parsed Body
Pick the request you want to extract the response from. Enter the JSON key path. Make it explicitly JSON format (Automatic uses the Content-Type, which may not match in some cases).
The Copy as Dynamic Value may not work if your response is not interpreted as JSON, maybe the server is not setting a Content-Type: application/json header?
"Accept" is not listed in the forbidden headers in the documentation here:
http://livedocs.adobe.com/flash/9.0/ActionScriptLangRefV3/flash/net/URLRequestHeader.html
but cant seem to set it in a GET request. Help!
You are allowed to specify the "accept" header, but only on a POST request with one or more variables.
The documentation comments mention this:
For browser-based Flash/AS3 applications, the only way to successfully set
or modify request headers on a URLRequest object is to set its method to
POST as well as send at least one variable of data along with the request
(i.e. with URLVariables). Otherwise the headers will silently remain
unchanged.