I'm trying to build a decent mock API using Postman, and I stumbled upon its Matching algorithm.
Is there a way to turn it off, so that, for example, when I target the wrong query params, or simply the wrong URL, it does return a 404?
Currently the response from
my/api/path/endpoint?myParam=Test
is returned even when I submit to
my/api/path/endp
Which I really don't want.
Currently, there is no way to turn off query param matching. If the query params do not match the algorithm falls back to match the path. The path matching is based on a fuzzy string matching algorithm which is why you are getting a response even though you were expecting a 404. One workaround for this is to save another example response for with a response code of 404 for my/api/path/endpoint and then send the x-mock-response-code header key with the value 404. This should return the example you have stored with the 404 status code.
Related
Hello.
I met the following problem.
What I should do:
I need to make a performance test of services. I don't have documentation. In this case, I record the requested services and responses using Jmeter and the browser. Then I review every one sample and add a regular expression extractor - if it's needed.
What's the problem?
The problem that I met is when I run the script from Jmeter, some requests have two or more responses. When I use regular expression extractor or response assertion, I noticed that the extractor or assertion is applied only to the last response. So can I apply the regular expression extractor and response assertion to responses that I need?
Here are some screenshots for more details:
This picture shows that we have two responses from one request and you can see details about the first response.
This picture shows details about the second response.
This picture shows the response code for the first response.
Same as the previous picture, but I added a Response Assertion - to check if the assertion works for the first response.
This picture shows the response code for the second response.
This picture shows the assertion failure.
Why has this has happened?
Probably this happened because I hit an URL (endpoint), and this URL forces other requests, that weren't recorded. So... maybe I need to configure the recorder options in another way.
Whats the questions:
Is there is a way to choose what response I can use with a regular expression extractor? For example, there are two responses and I want to use a regular expression extractor to the first one.
Which are the best settings for recording using Jmeter?
"Whats the answers":
No, you have choice between Main sample and sub-samples, main sample only, sub-samples only or JMeter Variable
The ones which are defined in the Recording Template are most probably the best, at least they're better than anything else I've seen so far. The general approach of "recording" might be a big mistake itself, at least for Web 2.0, I believe there are way better options of replicating browser traffic.
Coming back to your first question and possible solutions: you're basically being redirected that's why you're getting 2 subresults, one with status code 302 and another one with 200
With normal Response Assertion you can only amend its configuration to take both status codes as successful:
If you want to test that exactly the first subresult has status code of 302 - you will have to go for JSR223 Assertion and implement the acceptance criteria in Groovy.
Example code:
if (prev.getSubResults().first().getResponseCode() != '302') {
AssertionResult.setFailure(true)
AssertionResult.setFailureMessage('Response code mismatch, expected: 302, got: ' + prev.getSubResults().first().getResponseCode())
}
I am currently receiving 400 errors when invoking the list_builds() method (seen here: https://googleapis.dev/python/cloudbuild/latest/gapic/v1/api.html?highlight=list_builds#google.cloud.devtools.cloudbuild_v1.CloudBuildClient.list_builds)
The following command works using gcloud:
gcloud builds list --filter="status=FAILURE"
However, the following API call returns google.api_core.exceptions.InvalidArgument: 400 Error processing filter expression
for element in client.list_builds("REDACTED", filter_="status=FAILURE"):
# process element
pass
I'm guessing I'm missing something very obvious and simple here but I can't exactly figure out what I'm doing wrong
The correct way to pass in the filter string to the API call includes using double apostrophes around the actual text like so:
filter_='status="FAILURE"'
Unsure of whether or not this will be changed in the future, but this is the same behavior for passing it in via the REST API here: https://cloud.google.com/cloud-build/docs/api/reference/rest/v1/projects.builds/list
e.g specifiying status=FAILURE will fail, but status="FAILURE" returns a 200 response.
welcome to Stack O! So I'm just spitballing here, but the docs say that the Filter string is "The raw filter text to constrain the results."
When you filter a Cloud Build in the console, the "raw filter text" in the UI says Status : Failed - you could try:
--filter="Status : Failed"
--filter="Status: Failed"
--filter="Status:Failed"
Alternately, it might be the string in the URL, the formatting of which is too bananapants for Stack O's robots to handle, so I can't paste it here, but it starts with f and ends with Failed:
The key here is that you have an equal sign in your string, as well as Failure instead of Failed - changing one or both of those might do the trick.
Hope this helps!
If I send a query to Google Webmaster Tool API (Search Console), it returns an error - 404 status.
Here is a query
https://www.googleapis.com/webmasters/v3/sites/www.kvadroom.ru/urlCrawlErrorsSamples/obyavleniya%2Fprodaetsiya-taunhaus-sinkovskoe%2F201437169.html?platform=web&category=soft404&access_token=ya29.FgJLUjBKLvoQWXEJN6MsHPl4awqXr33uk8wIiCN_z4WWp4175JyrQeQRjmhGfIU6pMbF
(of course token has already expired, but was actual when used. Anyway, it's not a matter of credentials)
As you can see, a part of query string is escaped - it's a requirement of GWT API - https://developers.google.com/webmaster-tools/v3/urlcrawlerrorssamples/get
If I paste query string to browser's adress bar, I get status Ok 200 with JSON response. But if I use the same query in PQ's Web.Contents, PQ parses string incorrectly - it converts (but should not) "%2F" to "/"
It says
Is it a bug or I do something wrong?
Suppose it happens only when escaped string is used in /path/ but not in ?params, i.e. precedes question mark
Update: This is a (unwanted) feature of the URL library we are using: https://msdn.microsoft.com/en-us/library/ee656542(v=vs.110).aspx
We're currently not able to support this scenario.
For anybody frustrated by this, consider starting a topic at https://ideas.powerbi.com
Nice find!
I'm not able to find any workaround to get Power Query to make a request with "%2F" in the path.
Sorry about that. I'll add a bug to our team's backlog.
Using the latest versions of Flask and Flask-RESTful, I have some very basic routes defined as such:
def build_uri_rules(uri_map):
for cls, uri in uri_map.iteritems():
api.add_resource(cls, uri)
uris = {
SampleController: '/samples/<string:hash_or_id>',
SampleFamilyController: '/samples/<string:hash_or_id>/family',
}
build_uri_rules(uris)
This works for uris requested 'properly', but what if the /samples/ endpoint is hit without a parameter, or the sample*family endpoint is hit with an empty sample id? Currently, this results in a 404 error. This works well enough, but I believe the proper thing here would be to throw a 400 error, as they found a proper URL but their data is improperly structured. Is there a way that I can force this behavior?
As a side note:
Looking through the Werkzeug docs, I see that werkzeug.routing allows a minimum length for certain url parameters, but I also see that it's got a minimum of 1. Admittedly, I've not look for why this is the case, but would this be the right tree to bark up? or should I rather simply create a global 404 handler that checks for the length of the parameter and raise the proper error from there?
Thanks!
EDITED: For code correctness.
I would say that hitting /samples/ or /samples/family (or even /samples//family) should result in a 404 as there is nothing at that endpoint.
If, however, you want to do otherwise, the simplest way to handle it would be create a 404 handler for just /samples/ and /samples/family that returns a note with more information about what the consumers of your API are most likely doing wrong.
uris = {
Explanitory400Controller: '/samples/',
SampleController: '/samples/<string:hash_or_id>',
Explanitory400Controller: '/samples/family',
SampleFamilyController: '/samples/<string:hash_or_id>/family',
}
Our team is developing RESTFul applications...we are debating the "BEST PRACTICE" approach.
Should 404 status code response be returned for a filter-like query? Say my GET URL is
.../1/service/startsWith/a.json
and it returns all values that start with A in my database...but if no "a" values are found should i just return status code 200 with an empty json string? or status code 404.
Thanks!
See this question, in the update to my answer I address your issue.
Specifically this bit,
I think the answer to whether to
return 404 depends on the what is the
resource that is being retrieved. Is
it a representation of a search
result, or is it a representation of a
product? To know this you really need
to look at the link relation that led
us to the URL.
If the URL is supposed to return a
Product representation then a 404
should be returned if the code does
not exist. If the URL returns a search
result then it shouldn't return a 404.
The end result is that what the URL
looks like is not the determining
factor. Having said that, it is
convention that query strings are used
to return search results so it is more
intuitive to use that style of URL
when you don't want to return 404s.
It may be more sensible to return a 204 code, which means 'No Content'. This would be slightly more efficient as a 204 status cannot have any document content, plus you can detect the code instead of having to parse the response.