What I'm trying to do is hit a service twice in a row with a post of the same data. The idea here is to confirm that I can't have duplicate data, so I should get a 422 and a specific message in the response.
The test looked something like this:
When javaClient.createFoo(parameters)
And javaClient.createFoo(parameters)
Then status 422
And match $.message == "This is a duplicate."
It doesn't have a problem matching the status of the second call, but when I try to match the message (or any part of the response) it compares to the response from the first call.
I've tried making the second call a When, tried checking the status of the first call in between, but there must be something else that I'm missing.
Any ideas? Is there something special I need to do to clear the response?
Unless the method step is called, Karate does not do anything. The use of javaClient.createFoo() (whatever that is) suggests that there are some fundamental problems in your use and understanding of Karate.
I suggest keep it simple and just repeat the method post with the same payload and it should work as you expect.
Also please read this: https://stackoverflow.com/a/54126724/143475
Related
I have some records in the database that may or may not have some information for a certain column, and that's OK.
If a consumer of the endpoint runs into one of these records, I'd like to return "NoContent", because, well, there's No Content for that record that we can execute on. BUT ... I'd like to give them a message why, as there are two distinct reasons.
When looking at other status codes, this works:
return Accepted("I SEE THIS STRING!");
It actually shows up in the Response Header as the field location (I think, don't make me run this project again!)
This works for say Internal Server error:
return StatusCode(500, "I SEE THIS TOO!");
But, for NoContent there is no constructor like Accepted, where you can pass an object. Also, this shows me no string whatsoever:
return StatusCode(204, "WHY CAN'T I SEE THIS STRING?!");
Help!
204 (No Content) returns an HttpResponseMessage with, well, No Content.
If you do have content to return that the user can consume (the two reasons), then you don't have a No Content scenario.
Perhaps an Ok (200) with a custom ContentNotProvided class that holds a message, which can be consumed by the client, will do the trick?
Alternatively, return a BadRequest (400) with a message.
Does anyone know the difference between process_spider_input(response, spider) in spidermiddleware and process_response(request, response, spider) in Downloadermiddleware.
And how to choose one over another, because I see they do quite the same work, they handle response.
According to the source, they do have difference
return value
spider_mw.process_spider_input() returns None, you can check or modify the Response. Basically it supposes the response has been accepted and you can't refuse it.
downloader_mw.process_response() returns Response or Request. You can refuse the response from download handler and generate a new request. (e.g. the RetryMiddleware）
I am building an API about email auth code.
Its process is simple.
input random code (client browser)
request with input code. (client browser)
receive the request (server)
scan the code from DB (server)
there is no code matched (server)
return a response with status code.
There are many status code, (2xx, 4xx, 5xx);
but I don't know which status code number is the most proper for this case.
It depends on the semantics you want to give your request. E.g.:
The API should search for items matching the query and return a list of results, like GET /codes?q=4ba69g. Think a "search page". In this case, an empty result [] is a perfectly valid result; nothing was wrong with the query, it just didn't return any matches. That's a 200 OK, or maybe a 204 No Content if you want to omit the empty response body entirely.
The code is treated like a resource, e.g. GET /codes/4ba69g. In this case a missing code would result in a 404 Not Found.
It's an action you want to perform which may fail, e.g. POST /login. If the user supplied the wrong credentials/code and hence the action cannot complete, that's a client-side error and therefore a 400 Bad Request.
I have a web_custom_request method that needs to handle dynamic item data
web_custom_request("create",
"URL=someurl\create",
"Method=POST",
"Resource=0",
"RecContentType=application/json",
"Referer=someurl",
"Snapshot=t6.inf",
"Mode=HTML",
"EncType=application/json",
"Body={\"actions\":{\"name\":\"value\"}}"
LAST);
To address the dynamic name-value pair parameters that come into play, I had built a bufferthat would hold the Body string. I have used correlation and looping to achieve that. Code towards the end of building this buffer looks like this
lr_param_sprintf("s_buffer", "\\\"actions\\\":{%s}",paramStr);
lr_output_message("Final Actions string is %s", lr_eval_string("{s_buffer}"));
Output for above lr_output_message is
Final Actions string is \"actions\":{\"name\":\"value\"}
I replaced Body parameter in web_custom_request with the buffer I had built
web_custom_request("create",
"URL=someurl\create",
"Method=POST",
"Resource=0",
"RecContentType=application/json",
"Referer=someurl",
"Snapshot=t6.inf",
"Mode=HTML",
"EncType=application/json",
"Body={s_buffer}"
LAST);
I receive a HTTP Status-Code=400 (Bad Request) indicating the format of web_custom_request is wrong. I would highly appreciate if someone could help me with the Body parameter so that the web_custom_request embraces it like the way it should.
Record it three times. First two with the same login session. The third with another one. You likely have something that is going to change based upon data which is not being handled in the body appropriately.
In the first header field of a http response message there is a status code (Eg.200,404,400) and phrase code(e.g.OK, NOT FOUND, Bad request). When we have a status code already, why do we need a phrase again? Wont that cause extra overhead?
A) Technically, that is not a header field. The first line simply is special.
B) It's not needed and optional, and yes, it causes overhead.