My API consumes requests only with Header - Content-type:application/json object.
To do the same I use:
#OA\RequestBody(
description= "Provide company search parameter",
required= true,
#OA\JsonContent(
type="object",
#OA\Property(property="company_name", type="string")
)
)
But for some requests I don't need the RequestBody, only hit the resource and get data. How do I do it without RequestBody?
P.S. This request requires a GET method (POST can be used, if that helps) but GET doesn't accept a RequestBody.
This case cannot be described by OAS 3.0, and the restriction on GET requestBodies is to avoid attempting to describe API behaviour which the HTTP spec says is undefined. The restriction on specifying Content-Type as a 'manually' defined header is also to ensure there is no ambiguity as to which mechanism is supposed to set this header.
https://github.com/OAI/OpenAPI-Specification/issues/1628
When a client is sending the Content-Type header, it is used to describe the body of the request (not the response)
To influence the the response type a client can send an Accept header.
For example: Accept: application/json
Related
My spec is as below.
/path:
/user:
get:
parameters:
- name: Authorization
in: header
required: true
schema:
type: string
Problem is that it is giving me the below warning. I get the same warning if I add Content-Type or Accept header.
Header parameters named Authorization are ignored. Use securitySchemes and security to define the Authorization
I tried the below but I don't see Authorization header added in the request. I am using https://editor.swagger.io to create the spec.
/path:
/user:
get:
parameters:
- name: Authorization
in: header
required: true
schema:
type: string
security:
- my_auth: []
components:
securitySchemes:
my_auth:
type: http
scheme: bearer
bearerFormat: JWT
Any help is appreciated. Thanks !!
In the request parameters, there are operation's specific parameters.
The general purpose HTTP headers aren't defined here because:
Content-Type is defined by the request body content. If there are multiple content types, the consumer has to choose and set Content-Type accordingly.
Accept is similar; it only relates to the response message.
For security, we do not describe the Authorization header but instead define the security scheme (see docs for more).
You may use the description property to explain how to use these headers with your API. However, if your API follows standards, it should not be necessary.
Once you have added the security schema to your API definition, you can use the Authorization function of Swagger Editor. So, you will add your token and trigger "Try it out." Swagger will populate the Authorization header; see the attached screenshot.
I used Charles to record a session and when I check one of the sessions, I found that there is no request body but I can see a response body, I am confused about this as how am I seeing a response without sending a request?
Also, I noticed that I can choose to see the request and response body on my phone's Charles, but on my desktop Charles, I can only see the tab called Content, I tried clicking on the request and response in the under the View tab, nothing happened as well. Does anyone know why?
Thanks!
I am confused about this as how am I seeing a response without sending a request?
A request consists of a few things:
Always: an HTTP method (GET, POST, or similar)
Always: a path (/document/123)
Optional: any number of HTTP headers (my-header: abc)
Optional: a request body
A response consists of:
Always: an HTTP status (404)
Always (in HTTP/1): an HTTP status message (Not Found)
Optional: any number of HTTP headers (my-header: abc)
Optional: a response body
In your case, you are sending a request, it's just that your request only contains a method, URL and headers, but no body. That's totally normal and this is very common for most HTTP requests.
The request and response body are totally independent: it's fine for neither to have a body, or for just one (either one) to have a body, or for both to have a body.
As an example, a GET request to https://google.com/search from a browser will include a method (GET) and a path (/search) and a selection of headers from the browser (such as a user-agent), but won't include any body, and the response will have a status (200) and message (OK), headers about the response data (e.g. content-length: ...) and the body will be the HTML for the google search page.
When I try to call:
POST /oauth2/v1/tokens/bearer?grant_type=authorization_code&code=XXX&redirect_uri=https://developer.intuit.com/v2/OAuth2Playground/RedirectUrl
Content-Type: application/x-www-form-urlencoded
Accept: application/json
Authorization: Basic XXX
I get Status: 400 Code: InvalidFieldFormat Type:SYSTEM from every platform (curl, postman, mongodb stitch). The only place where it works is the intuit playground.
I do not see what is invalid.
You're trying to pass everything via a query string, and you should be passing it in the POST body.
You should be POSTing to this URL: https://oauth.platform.intuit.com/oauth2/v1/tokens/bearer
And passing in a HTTP request body like this:
grant_type=authorization_code&
code=L3114709614564VSU8JSEiPkXx1xhV8D9mv4xbv6sZJycibMUI&
redirect_uri=https://www.mydemoapp.com/oauth-redirect
It's the POST body, not the query string.
This is documented on Intuit's site here:
https://developer.intuit.com/app/developer/qbo/docs/develop/authentication-and-authorization/oauth-2.0#step-5-exchange-authorization-code-for-refresh-and-access-tokens
I created an AWS API-gateway for an HTTP method PUT. When I do a test in API-gateway, that works fine, but when I call it from a REST client, I get 404 bad-request and missing authentication token errors. I didn't set any authorization to true or a required API key to true.
I passed these query parameters to a REST client:
auth_id : 8798iuyiu123123
time_stamp :1231231
test_json : [{"id"=>"1","value"=>"mount"},{"id"=>"2","value"=>"chart"}]
HEADER
content-type : application/json
When I change the test_json value to %5B%7B%22id%22:%221%22,%22value%22:%22test%22%7D,%7B%22id%22:%222%22,%22value%22:%2213+%D8%B4%D8%A7%D8%B1%D8%, then I get the response.
i am new to react, calling from react
Request.put('https://api-gateway.sqwdwed123.com/eretw/update-chart')
.set('Content-Type', 'application/json')
.query({ auth_id: localStorage.auth_id})
.query({ time_stamp:this.props.time_stamp})
.query({ test_json:JSON.stringify(newadd)})
should i pass this test_json through body?
Am I doing anything wrong?
This is usually related to requesting a URL that doesn't exist. Please make sure you're using the correct HTTP method and resource path to a valid resource (the sample invoke URL does not include any resource path). If this still doesn't work. Make sure you actually deployed your API.
The HTTP Response of Bad Request is because you have the Query Parameter that are not URL Encoded. There are 2 things that you can do now:
Pass the test_json as Query Param but making sure that they are URL Encoded. This will put a restriction on the size of the string and hence Not Recommended.
Pass the test_json as Request Body. (Recommended)
I am trying to create a PUT request using Fiddler but I am constantly receiving an error as follows.
PUT Request
https://127.0.0.1/odata/ControllerName('param')
Request Header
Accept: application/json;odata=minimalmetadata
Host: 127.0.0.1
Authorization: ApiKey uniqueKey
Content-Type: application/json;odata=minimalmetadata
Accept-Charset: UTF-8
RequestBody
{"Name":"param"}
When I am trying to PUT, it returns me status code 400. When I double click error in fiddler and view JSON tab, it gives me following error.
odata.error
innererror
message=actionParameters : The last segment of the request URI 'ControllerName('param')' was not recognized as an OData action.
Where I am going wrong, with URI format or request body?
According to OData protocol,
the value within the parenthesis following the entity set(corresponds to a controller) must be a key, for example:
~/odata/Products(1) if the key is of int type,
~/odata/Products('1') if the key is of string type.
So please make sure the key is of string type in your case, and try to
GET https://127.0.0.1/odata/ControllerName('param')
to see whether the response is as expected.