Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 4 years ago.
Improve this question
I have Postman collection to run POST request 10 iterations, in each iteration I have different values for the variables in the request body, and I am doing that by using CSV.
After completing running the collection, I cannot see the "Response Body" for each iteration. it shows data for the test results and statistics, but not for the actual response body.
Is there any idea to how I can get the response body for each request/iteration in the collection, is that not available in Postman, is there any other tools can do that?
More simplistic way is:
tests[`Response Body: ${responseBody}`] = true;
In the latest version (5.5.0) you can see the response data for each request by clicking on the request name in the Collection Runner. This will give you the details about the request made and the response received.
You can get the response body like this in your test section:
const body = pm.response.json();
Then you can print it in your test results as:
tests["Response Body ", body] = true;
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I'd like to see if an HTTPURLResponse statusCode begins with 2 to indicate success. Does it make more sense to see if it falls between 200 and 299, inclusive? Or does Swift have a builtin function to see if an HTTP status code represents success?
That is, given,
var statusCode: Int = ..
which, if any, of the following expressions would be preferred?
let success = String(statusCode).prefix(1) == "2"
let success = statusCode < 300 && statusCode >= 200
The relevant documentation reads,
The first digit of the Status-Code defines the class of response. The
last two digits do not have any categorization role. There are 5
values for the first digit:
- 1xx: Informational - Request received, continuing process
- 2xx: Success - The action was successfully received,
understood, and accepted
- 3xx: Redirection - Further action must be taken in order to
complete the request
- 4xx: Client Error - The request contains bad syntax or cannot
be fulfilled
- 5xx: Server Error - The server failed to fulfill an apparently
valid request
https://www.ietf.org/rfc/rfc2616.txt
You are right that anything between 200 and 299 (inclusive) means success.
However, it's not a complete picture. A 3XX response might mean that you don't know if the request is successful yet, and you need to follow the redirect to find out what the real status was.
A 303 redirect can lead to a URI that returns a 404, or a 200 OK.
Closed. This question is not reproducible or was caused by typos. It is not currently accepting answers.
This question was caused by a typo or a problem that can no longer be reproduced. While similar questions may be on-topic here, this one was resolved in a way less likely to help future readers.
Closed 3 years ago.
Improve this question
Here's my header:
Accept: 'application/json',
'Content-Type': 'application/json',
'Cache-Control': 'no-cache',
'x-apikey': 'some-api-key',
When I send a GET request with the query /users?q={"firstname": {"$regex": "jo"}} after refreshing the page with ctrl+f5, the response match the query. When after that first request, I try another query: /users?q={"firstname": {"$regex": "nat"}}, the request to the server is successful (200), but the body response is the same than for the first query. I have to manually press ctrl+F5 to make the answer match the query, and it works kind of randomly, I'm not able to understand any logic. Get resquests like /users?skip=25&max=25 works perfectly, so must be link to the use of the query string params.
I try all the possibilities of 'Cache-Control, but nothing worked.
thanks!
Sorry, but this was due to an aggressive cache on a particular service, should be working fine now.
Closed. This question is not reproducible or was caused by typos. It is not currently accepting answers.
This question was caused by a typo or a problem that can no longer be reproduced. While similar questions may be on-topic here, this one was resolved in a way less likely to help future readers.
Closed 3 years ago.
Improve this question
I get a guzzle error as above , when i am sending the following code from a drupal 8 site:
$url="https://mywebsite.com/index.php";
$client = \Drupal::httpClient();
$client->setDefaultOption( array('verify' ,false));
$post_data = $form_state->cleanValues()->getValues();
$request = $client->post($url, $post_data);
This line was causing it to think this was the URL. When I took it out it works okay
$client->setDefaultOption(array('verify', false));
Basically, it should work (because the $url obviously is a string).
If it doesn't, check the stack trace of the exception (is it this call, or maybe another?).
And provide the Guzzle version please.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
Wanted to get your opinion on this, probably there's isn't an absolute right answer, but I want to see what you think is the more correct approach.
If there's nothing structurally wrong with a request (it's in the correct format) and all the fields are valid (field values not too long, required fields have a value etc...) but the call failed because of a business reason, for example "you cannot change a status of task that isn't assigned to you", what should be the response in this case:
200 with a JSON which explains the error:
{
error: {
code :120,
message: "you cannot change a status of a task that isn't assigned to you"
}
}
or maybe a 4xx response with a similar body:
{
error: {
code :120,
message: "you cannot change a status of a task that isn't assigned to you"
}
}
While I want to agree with #EJK, the spec he linked is out of date.
The most current one is RFC7231: https://www.rfc-editor.org/rfc/rfc7231#section-6.5.1 which changed the meaning of the old 403 FORBIDDEN response status.
Answer:
So for the sake of this question 400 BadRequest should be used, because whoever consumed your service, case being the client, is wrong and can possible fix his request
The 400 (Bad Request) status code indicates that the server cannot or
will not process the request due to something that is perceived to be
a client error (e.g., malformed request syntax, invalid request
message framing, or deceptive request routing).
An example from your own use case:
The client now knows that the error "you cannot change a status of a task that isn't assigned to you" is his own fault. And he may even try to issue a different new (valid) request.
403 Forbidden seems like a good match.
From http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.4.
The server understood the request, but is refusing to fulfill it.
Authorization will not help and the request SHOULD NOT be repeated. If
the request method was not HEAD and the server wishes to make public
why the request has not been fulfilled, it SHOULD describe the reason
for the refusal in the entity. If the server does not wish to make
this information available to the client, the status code 404 (Not
Found) can be used instead.
Thus, option 2, as you have proposed, seems good as it also describes the reason for the failure.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
In my continuing quest to try and wrap my mind around RESTful-ness, I've come to another place where I'm not sure how to proceed. I set up a thought expiriment for myself where I'd design a simple voting system for a resource, much like how SO allows voting on questions. So, say my resource is an image, and I can get an image by an ID, like so:
http://www.mysite.com/images/123123
And in this example, that returns say, a JSON representation of an image, like so:
{
"URL":"http://www.mysite.com/images/123123.jpg",
"Rep":"100"
}
How would I design a way to "vote" on that image? I'd like two operations; up-vote and down-vote. The client shouldn't know how much weight each carries, because I'd like to have the award for an up-vote/down-vote be decided at the server level so I can change it anytime I like.
My first idea was to have something like this:
http://www.mysite.com/vote/images?image=123123
To that URL, one could POST something like the following:
{
"Vote":"UpVote"
}
But I'm wary of that - to me that says RPC in disguise. Would that be a poor way to design this? If so, what other designs could I try?
To be restful you should return something like this
{
"URL":"http://www.mysite.com/images/123123.jpg",
"Rep":"100"
"UpVoteLink":"http://blah, blah, blah",
"DownVoteLink":"http://blah, blah, something else blah",
}
As far as REST is concerned it doesn't matter what the format of the links are. As long as your client knows that it is supposed to do POST to the "UpVoteLink" or "DownVoteLink" it couldn't care less what the format of the URL is.
Also, if you decide in two weeks that you don't like the URLs you picked, you can change them and no-one will care!
Ok, ok, if you really want a suggestion for an url design, how about
POST http://www.mysite.com/UpVotes?url=http://www.mysite.com/images/1234.jpg
POST http://www.mysite.com/DownVotes?url=http://www.mysite.com/images/1234.jpg
What is cool about this design is that you could vote on images that are not even on your site!
In terms of resources, an image is a thing that has a URI (that is what makes it a resource). Further than that, it has a bunch of properties (size, EXIF data, etc).
When you think of the votes for an image, question if the votes are a resource in themselves.
Chances are, doing a GET on /images/23/votes would return a summary or the list of all votes that the UI would use to display next to the image. Whenever you want to change those votes, the resource you're changing is the votes.
To be restful, the client needs to only understand the media type you've designed, not the URIs or the process to follow to vote.
In your example, you'd define a new format used everywhere on your site. To reformulate yoru example, a GET /images/23/votes would return (in xml but you can reformulate it in json):
<votes>
<link href="/images/23" rel="subject" />
<form action="/images/23/votes" mediatype="application/json">
<submit name="Vote" value="Up">Vote up</submit>
<submit name="Vote" value="Down">Vote down</submit>
</form>
</votes>
The idea behind this format is that you have a universal way to define how the client sends the data to the server and build the document. All the previous examles that have been shown correctly make the URI dependent on the server. I propose that what you send to the server should be defined in forms that the server sent.
So spend more time defining how yoru json client is going to understand how to build json objects for submission based on a general form language, and you'll find that once this is done, you have very low coupling between cient and server, and the server has the flexibility to change all the specifics without breaking your clients.
REST APIs are supposed to represent nouns so I think you've the first part correct: a single image is represented by a single URL (e.g. http://www.mysite.com/images/123123). I'm not sure tacking on /up_vote and /down_vote is the way to go though.
http://www.mysite.com/images/123123 is the object and you want to modify that, not some other URL (unless you were doing http://www.mysite.com/votes/images/123123). I think you should just POST to http://www.mysite.com/images/123123. This makes GET requests inherently non-destructive since it just retrieves the image, preserves a RESTful design, and keeps your URLs clean.
If you're working with Rails, I'd go for this GET-URLs:
http://www.mysite.com/images/123123/up_vote
and
http://www.mysite.com/images/123123/down_vote
1.
Define the actions "up_vote" and "down_vote" in your Images controller and have it increase or decrease the vote value of your image-model-object.
2.
Set the following route in config/routes.rb:
map.resources :images, :member => { :up_vote => :get, :down_vote => :get }
...and you're done (more or less ;-)).
It would seem silly to me to POST a simple response like that wrapped in JSON
Why not something simple like this, you could do it in an AJAX call to make it uber nice..
A GET request formatted as follows
http://www.mysite.com/vote.php?image=123&vote=up
or POST (this example using jQuery)
$.post("http://www.mysite.com/vote.php", {image:"123", vote:"up"});
(Assuming PHP, but whatever applies)