I am attempting to create a custom connector for MS Flow\Logic Apps that uses some of the REST endpoints that are part of the microsoft graph but am having trouble in understanding how to document the API in OpenAPI 2.0 specification
The MS documentation
https://learn.microsoft.com/en-us/graph/api/group-post-owners?view=graph-rest-1.0#example
says to include
"#odata.id": "https://graph.microsoft.com/v1.0/users/{id}"
as a $ref parameter as part of the request body
but how do I document this in OpenAPI 2.0 specification?
This is what I have got so far...
'/groups/{team-id}/owners':
post:
tags:
- teams.team
summary: Add a new owner to the team
operationId: teams.AddOwner
consumes:
- application/json
parameters:
- name: team-id
in: path
required: true
type: string
description: Id of the MS team
x-ms-summary: Team Id
x-ms-visibility: important
- name: body
in: body
required: true
schema:
type: object
properties:
userId:
type: string
description: Id of the user to be added as an owner to the team
x-ms-summary: User Id
x-ms-visibility: important
'#odata.id':
default: https://graph.microsoft.com/v1.0/users/{userId}
responses:
'204':
description: Success
default:
$ref: '#/responses/error'
x-ms-docs-operation-type: operation
When I submit the above to create the custom connector I get the following error
Specified file does not match OpenAPI 2.0 specification: 'JSON is valid against no schemas from 'oneOf'. Path 'paths./groups/{team-id}/owners.post.parameters[1]'.'
EDIT
I have updated the OpenAPI to look like below
This means that I can import and use this... but I have to construct the URL for the #odata.id parameter manually in the workflow!
"#odata.id": "https://graph.microsoft.com/v1.0/users/{id}"
'/groups/{team-id}/owners/$ref':
post:
tags:
- teams.team
summary: Add a new owner to the team
operationId: teams.AddOwner
consumes:
- application/json
parameters:
- name: team-id
in: path
required: true
type: string
description: Id of the MS team
x-ms-summary: Team Id
x-ms-visibility: important
- name: body
in: body
required: true
schema:
type: object
properties:
'#odata.id':
title: User Id
type: string
x-ms-summary: User Id
x-ms-visibility: important
responses:
'204':
description: Success
default:
$ref: '#/responses/error'
x-ms-docs-operation-type: operation
EDIT
How should I be specifying this to get the userId?
How do I specify the body parameter correctly?
Is there any documentation\examples on how to do this?
Any help would be much appreciated
Thanks in advance
Pete
One of the easiest ways I’ve found to create a PowerApps Custom Connector is to:
Use Postman to craft a working request
Build the Custom Connector from Blank
Test in the Custom Connector “Test” area
Then, you can download the Swagger file if you need it. Basically, let PowerApps build the Swagger file FOR YOU instead of the other way around.
Here is a YouTube video of the method I like to use.
https://m.youtube.com/watch?v=-wQljWG35zM
Related
I've API Spec specified in OAS 3.0
post:
tags:
- One Time Payment
summary: One Time Payment API
operationId: oneTimePaymentUsingPOST
parameters:
- in: body
name: realTimePaymentRequest
description: realTimePaymentRequest
required: true
schema:
$ref: '#/components/schemas/RealTimePaymentRequest'
When I edit this spec file in https://editor.swagger.io/ - It's throwing errors as :
Structural error at paths./banks/payments.post.parameters.0.in
should be equal to one of the allowed values
allowedValues: path, query, header, cookie
I can see that describing in: body in parameters is supported as per https://swagger.io/docs/specification/2-0/describing-request-body/
thought Swagger Editor is throwing errors. What could be wrong here ? schema ?
Any help is appreciated. Thank you.
In OpenAPI 3.0, in: body and in: formData parameters were replaced with requestBody:
post:
tags:
- One Time Payment
summary: One Time Payment API
operationId: oneTimePaymentUsingPOST
requestBody:
description: realTimePaymentRequest
required: true
content:
application/json:
schema:
$ref: '#/components/schemas/RealTimePaymentRequest'
The documentation link you posted is for OpenAPI 2.0. For OpenAPI 3.0, use this link:
https://swagger.io/docs/specification/describing-request-body/
I'm using http://editor.swagger.io to design an API and I get an error which I don't know how to address:
Schema error at paths['/employees/{employeeId}/roles'].get.parameters[0]
should NOT have additional properties
additionalProperty: type, format, name, in, description
Jump to line 24
I have other endpoints defined in a similar way, and don't get this error. I wondered if I had some issue with indentation or unclosed quotes, but that doesn't seem to be the case. Google also did not seem to provide any useful results.
swagger: "2.0"
info:
description: Initial draft of the API specification
version: '1.0'
title: App 4.0 API
host: api.com
basePath: /v1
tags:
- name: employees
description: Employee management
schemes:
- https
paths:
/employees/{employeeId}/roles:
get:
tags:
- employees
summary: "Get a specific employee's roles"
description: ''
operationId: findEmployeeRoles
produces:
- application/json
parameters:
- name: employeeId <====== Line 24
in: path
description: Id of employee whose roles we are fetching
type: integer
format: int64
responses:
'200':
description: successful operation
schema:
type: array
items:
$ref: '#/definitions/Role'
'403':
description: No permission to see employee roles
'404':
description: EmployeeId not found
Any Hints?
The error message is misleading. The actual error is that your path parameter is missing required: true. Path parameters are always required, so remember to add required: true to them.
Had the same problem. I accidentally mixed up the syntax from Swagger 2.0 with Openapi 3.0.x. In Openapi 3.0.x, definitions are redefined as components. In the online editor you can click on the button Edit > Convert to OpenAPI 3 to use Openapi 3.0.x.
Read more about components here.
Remark:
OAS 3 is the latest version of the
OpenAPI Specification.
For me the cause of the error was a missing a leading slash in the path (internal/resource instead of /internal/resource).
And yes the error message is extremely unhelpful.
In my case I was missing parameter definition in api definition
- name: parameterName
in: query
description: parameter's description here.
required: false
schema:
type: string
In my case it had the wrong indentation for the example. It was:
content:
application/json:
schema:
$ref: '#/components/schemas/someresponse'
examples:
example1:
value:
param1: "some string"
param2: "123"
Rather than:
content:
application/json:
schema:
$ref: '#/components/schemas/someresponse'
examples:
example1:
value:
param1: "some string"
param2: "123"
But the VScode open api preview with swaggerUI didn't show any errors and everything looked valid.
The syntax requires might require two parameters, as mentioned by Helen required: true is need so is type:DataType . The error is misleading.
I am starting a REST service, using Swagger Codegen. I need to have different responses for different parameters.
Example: <baseURL>/path can use ?filter1= or ?filter2=, and these parameters should produce different response messages.
I want my OpenAPI YAML file to document these two query params separately. Is this possible?
It is not supported in the 2.0 spec, and not in 3.0 either.
Here are the corresponding proposals in the OpenAPI Specification repository:
Accommodate legacy APIs by allowing query parameters in the path
Querystring in Path Specification
If you're still looking, I found out a way around this problem. It's a bit of a hack, but it works.
Basically, you can have two definitions to the same path by adding a slash (/) in the URL.
That way, you can set a response for <baseURL>/path with the ?filter1= parameter and set another response for <baseURL>//path with the ?filter2= parameter. It's also important that you give an unique operationId for each of the definitions.
paths:
/path/you/want:
get:
summary: Test
operationId: get1
parameters:
- name: filter1
type: string
in: path
required: true
responses:
200:
description: Successful response
schema:
$ref: '#/definitions/SomeResponse'
/path/you//want:
get:
summary: Another test
operationId: get2
parameters:
- name: filter2
type: string
in: path
required: true
responses:
200:
description: Successful response
schema:
$ref: '#/definitions/SomeOtherResponse'
I tried this with a path parameter and it worked just fine!
In swagger defining location,type explicitly is what defines these variables.
You have all the required fields to avoid collision of variables, for a json body you have to reference a declaration or use an example schema as shown below. For my case I have used a schema example rather than a declaration reference
/auth/account/password/reset/{userId}/{resetToken}:
post:
consumes:
- application/json
parameters:
- in: path
name: userId
type: string
required: true
- in: path
type: string
name: resetToken
required: true
- in: header
name: authorization
required: true
type: string
- in: body
name: body
required: true
schema:
type: object
example:
password: password
confirmPassword: password
responses:
"200":
description: OK
In Swagger you can add ? to make endpoints different.
i.e. /articles and /articles?:
When using ? in Swagger editor you will see error:
However on your final Swagger page there will be mark VALID
Additional information:
Remember about unique operationId for duplicated entries
I've created a swagger file that attempts to define the operations that I need from the Microsoft Graph API.
This API requires a couple of slightly complex data types to do things like creating users do I've therefore built these object and properties as a schema that provides a parameter 'parameters' in: body. See the snippets below.
I can register this Custom API in Flow but when I attempt to use an operation that has an in body parameter the action in Flow states that "This operation has no inputs."
/users:
post:
tags:
- User
summary: Create User
operationId: UserCreate
description: >-
Use this API to create a new User. The request body contains the user to
create. At a minimum, you must specify the required properties for the
user. You can optionally specify any other writable properties.
parameters:
- name: parameters
in: body
required: true
schema:
$ref: '#/definitions/UserCreateParameters'
description: Parameters to create a user.
responses:
'201':
description: >-
Created. Indicates success. The new user is returned in the response
body.
schema:
$ref: '#/definitions/User'
default:
description: Error response
schema:
$ref: '#/definitions/GraphError'
Definitions
PasswordProfile:
properties:
password:
type: string
description: Password
forceChangePasswordNextLogin:
type: boolean
description: Force change password on next login
required:
- password
description: Contains the password profile associated with a user.
UserCreateParameters:
properties:
accountEnabled:
type: boolean
description: Enable the account. If it is enabled then true else false.
displayName:
type: string
description: User display name
passwordProfile:
$ref: '#/definitions/PasswordProfile'
userPrincipalName:
type: string
description: >-
The user principal name (someuser#contoso.com). It must contain one of
the verified domains for the tenant.
mailNickname:
type: string
description: The mail alias for the user
immutableId:
type: string
description: >-
Needs to be specified if you are using a federated domain for the
user's userPrincipalName (UPN) property while creating a new user
account. It is used to associate an on-premises Active Directory user
account to their Azure AD user object.
required:
- accountEnabled
- displayName
- passwordProfile
- userPrincipalName
- mailNickname
description: Request parameters for create a new work or school account user
I've discovered that the definitions, even thought they are valid Swagger and are validated by Flow, needs to have a type of 'object'.
As such, UserCreateParameters should be followed but type: object. E.g.
UserCreateParameters:
type: object
properties:
I've now included this at the start of every definition and all the fields are appearing as expected.
# GET verb version of the "GetClientsForGadget" method from the original ASMX Service
/clients/ProspectClient/roleandcstbased/{OrgNmFilter}/{SortNm}?{UserName}:
get:
tags:
- Client
summary: Merging of GetClientsforGadget and GetClientsForUser
operationId: ClientsForGadgetGET
parameters:
- name: OrgNmFilter
in: path
description: Organization Name Filter
required: true
type: string
- name: SortNm
in: path
description: Sort Field
required: true
type: string
- name: UserName
in: query
description: User's Identity
required: false
type: string
responses:
200:
description: Output results for GetClientsForGadget endpoint
schema:
$ref: '#/definitions/ClientOutput'
Swagger is giving me not a valid parameter definition for this query parameter. If I remove all references to Username in the path and parameter definition, no issues.
According to the Swagger Specification, I believe I'm using query parameters right, but somehow it's not.
Realized the issue was in path. The path does not need to include the query parameter.
/clients/ProspectClient/roleandcstbased/{OrgNmFilter}/{SortNm}?{UserName}:
/clients/ProspectClient/roleandcstbased/{OrgNmFilter}/{SortNm}:
It only needs the query to be defined in parameters. Otherwise bugs the whole thing out.