is there a way to limit swagger query params? for example - if somebody submits a GET request like:
/users/bob?product=10
and accidentally typed in /users/bob?products=10 - is there a swagger property I can add that will then throw an error?
Swagger allows you to describe the REST APIs. If product is the only query parameter allow, then the server should throw an exception if it finds other query parameters in the request from the client.
In other words, there's no way in Swagger to say parameters with certain names are not allowed as other parameters not documented in Swagger are disallowed by default.
Related
I'm trying to retrieve insights for a location using the Google Business Profile API. I've tried a few approaches, but I always get an error about "Cannot bind query parameter".
According to the docs, I should be posting to this URL: https://mybusiness.googleapis.com/v4/accounts/xxx/locations:reportInsights
and in the body, pass in an array of locationNames, but when I do that, I get the error about "Cannot bind query parameter 'locationNames'".
So I just tried doing a GET on this URL and pass in the names on the name querystring and that worked just fine to get the high-level data.
https://mybusiness.googleapis.com/v4/accounts/xxx/locations:reportInsights?name=accounts/xxx/locations/xxx
So I know I have the right account ID, location ID, etc. But I need to be able to add in the basicRequest parameter so I can indicate which metric that I want to retrieve.
So I've POST to both of those URLS above with a body that looks like this:
{"basicRequest":{"metricRequests":[{"metric":"ALL"}],"timeRange":{"startTime":"2020-10-12T01:01:23.045123456Z","endTime":"2022-01-10T23:59:59.045123456Z"}}}
But again, I get the same errors about "Cannot bind query parameter" to field "basicRequest" (Same as when I tried to pass in the "locationNames" param in the JSON.
So clearly, I'm doing something wrong with how I am sending in the parameters in the body because it doesn't seem to think any of those parameter names are valid. My end goal is to be able to retrieve queries_direct, actions_total, etc.
I'm using Ruby, and there isn't a client library for it, so I'm just crafting the URLs and the JSON body and doing a GET or POST to it.
Greatly appreciate any pointers!
I was working on Swagger generated OpenAPI specification and I noticed that if we pass some extra fields in PUT/POST API endpoint, then the server doesn't throw any error, even though it process all valid/necessary field.
So my doubt is that
Should the server throw error in this case?
Is it the OpenAPI standard to allow unknown fields and then ignore them?
In Swagger specification 2.0 there is no option to reject the extra fields passed in the request body. Server will only accept those fields that are allowed in the request definition and other fields will be ignored.
If you want to disallow extra fields then you can handle these in the backend manually.
I am using swagger openapi specification 3.0 to generate swagger from my interface. I have a delete method where it accepts request-body. But according to RFC7231, DELETE does not accept any request body. Also Swagger-request body tells that so. But my API is designed to accept request body in DELETE operation. Is there any work around in creating swagger such that DELETE operation accepts request body. Currently what error I am getting from swagger generation is,
Sematic error: DELETE operations cannot have a requestBody
No, you cannot use the OpenAPI 3.0 Specification and Swagger tools to implement DELETE requests with a request body. As you correctly pointed out, the HTTP RFC says the DELETE request body has no defined semantics (and thus should be avoided), and OpenAPI 3.0 specifically disallows bodies in HTTP methods where the body does not have defined semantics. See this discussion for some context.
Consider changing your API design, for example, replace the DELETE body with path, query string or header parameters. Check out RESTful Alternatives to DELETE Request Body for some ideas.
This type of operation (DELETE, GET requests with a body) was explicitly banned in Open API 3.0. Prior to that it was allowed or vague.
I have a route defined like this:
from("direct:performEbayHttpCall")
.setHeader("HTTP_METHOD", constant("GET"))
.setBody(constant(null))
.log("${headers.EBAY_URL}")
.recipientList(simple("http://${headers.EBAY_URL}"))
.unmarshal().json(JsonLibrary.Gson);
When the log endpoint gets called the EBAY_URL is correct, I can copy and paste it into a browser and it works.
However when the http request is made, the url parameters are in completely the wrong order and thus causing a 500 response to be returned from the server.
Is there a way to tell camel to not mess about with the ordering of the url?
No the query parameter ordering should NOT matter. Any HTTP server should accept query parameters in whatever order they are, eg a=1&b=2 is the same as b=2&a=1
Camel validates and normalizes the URI and the query parameters is listed in A..Z order. (nor random).
I am receiving HTTP/SOAP request with some query parameters. Those query parameters are in repeated format as key=value as /q=key1=value1&key2=value2 etc...
I would like to retrieve all the keys from above URL and check if they are valid or not.
1. Is there any way to define global array which can hold these keys
2. How to validate if keys are present or not. Does ESB supports java "contains" API ?
I believe you are doing a GET request..
You can retrieve all the query parameters in a sequence.
eg:
For a request url; http:// localhost:8280/getSimpleQuote?symbol=IBM
<property name="symbol" expression="$url:symbol"/> will return the symbol 'IBM'.
After getting all keys, you can validate them
you can get the query parameters with the xpath expression get-property{'uri.var.xxx'} with xxx is the name of the query parameter you need to get.
When a resource is defined with a URL mapping, only those requests that match the given URL mapping will be processed by the resource. Alternatively one could configure a resource with a URI template. A URI template represents a class of URIs using patterns and variables. Some examples of valid URI templates are given below.
/order/{orderId}
/dictionary/{char}/{word}
All the identifiers within curly braces are considered variables. A URL that matches the template “/order/{orderId}” is given below.
/order/A0001
In the above URL instance, the variable orderId has been assigned the value “A0001”. Similarly following URL adheres to the template “/dictionary/{char}/{word}”.
/dictionary/c/cat
In this case the variable “char” has the value “c” and the variable “word” is given the value “cat”. When a resource is associated with a URI template, all requests that match the template will be processed by the resource. At the same time ESB will provide access to the exact values of the template variables through message context properties. For an example assume a resource configured with the URI template “/dictionary/{char}/{word}”. If the request “/dictionary/c/cat” is sent to the ESB, it will be dispatched to the above resource and we will be able to retrieve the exact values of the two variables using the get-property XPath extension of WSO2 ESB: