Skip to content

Conversation

@felixwa
Copy link
Contributor

@felixwa felixwa commented Mar 31, 2017

  1. Support Cognitive Services RP version - 2017-04-18
  2. Add following operations and related parameter definitions:
    a. POST updateAccountsCreationSettings
    b. GET accountsCreationSettings
    c. POST checkSkuAvailability
    d. Get operations
  3. Fix all issues reported by AutoRest/Validate-Spec/Validate-Example.
  4. Examples are removed from this swagger file – will add them to
    dedicated example folder later.

This checklist is used to make sure that common issues in a pull request are addressed. This will expedite the process of getting your pull request merged and avoid extra work on your part to fix issues discovered during the review process.

PR information

  • The title of the PR is clear and informative.
  • There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For information on cleaning up the commits in your pull request, see this page.
  • Except for special cases involving multiple contributors, the PR is started from a fork of the main repository, not a branch.
  • If applicable, the PR references the bug/issue that it fixes.
  • Swagger files are correctly named (e.g. the api-version in the path should match the api-version in the spec).

Quality of Swagger

1. Support Cognitive Service RP version - 2017-04-18
2. Add following operations and related parameter definitions:
a. POST updateAccountsCreationSettings
b. GET accountsCreationSettings
c. POST checkSkuAvailability
d. Get operations
3. Fix all issues reported by AutoRest/Validate-Spec/Validate-Example.
4. Examples are removed from this swagger file – will add them to
dedicated example folder later.
"required": true,
"x-ms-client-flatten": true,
"schema": {
"$ref": "#/definitions/CognitiveServicesResourceKindSettingUpdateParameter"

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ResourceKindSetting => AccountsCreationSettings?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changed.

"allowCreate": {
"type": "string",
"description": "Whether allow user to create resource.",
"enum": [

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does it support Boolean type?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It supports but AutoRest suggests to use Enum instead of Boolean.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the suggestion from AutoRest is to evaluate if the property is really a boolean or not, the intent is to consider if there could be more than 2 values possible for the property in the future or not, if the answer is no, then a boolean is fine, if the answer is yes, there could be other values, then make it an enum with values that represent what those should be. The idea is that it can help avoid breaking changes if you want to add one more possible value, naming the values "true", "false" I believe defeats this purpose.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changed to Boolean.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suggest AutoRest can turn off this warning though.

@salameer
Copy link
Member

salameer commented Apr 3, 2017

Hi @felixwa

@alvadb will be reviewing this PR very shortly, thanks for your patience! :)

@veronicagg
Copy link
Contributor

@felixwa thanks for submitting this PR.
If this spec is based on a previous api-version:
"When you are creating the swagger spec for the new api-version, please copy the swagger spec from the previous version in to the new api-versioned folder and commit it. After that overwrite it with the changes for the new api-version. This makes it easy for us to review the changes."
(https://github.com/Azure/azure-rest-api-specs/blob/c12accd4df379643a3aa9c5bf385e6f6ef50bf73/.github/CONTRIBUTING.md#filenames-and-folder-structure)
It's great to see linter validation is clean. Please consider if you'll be adding descriptions for the remaining warnings, as those would help with documentation (https://travis-ci.org/Azure/azure-rest-api-specs/jobs/217096052#L1022).
For a new api-version, we're requiring x-ms-examples, to make sure validation is clean against those.

Copy link
Contributor

@veronicagg veronicagg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comments inline.

"pattern": "^[a-zA-Z0-9][a-zA-Z0-9_.-]*$"
},
{
"name": "body",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should this be named "parameters"?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changed all places to "parameters".

"post": {
"tags": [ "CognitiveServicesAccounts" ],
"operationId": "CheckSkuAvailability_List",
"description": "Check availalable SKUs.",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

typo in "available"

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fix.

"200": {
"description": "OK.",
"schema": {
"$ref": "#/definitions/CheckSkuAvailabilityResultList"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is this a pageable operation?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No.

"/subscriptions/{subscriptionId}/providers/Microsoft.CognitiveServices/locations/{location}/updateAccountsCreationSettings": {
"post": {
"tags": [ "CognitiveServicesAccounts" ],
"operationId": "CognitiveServices_UpdateResourceKindSettings",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is this operation id accurate for the operation path?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed.

"$ref": "#/parameters/locationParameter"
},
{
"name": "body",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should this be named "parameters"?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changed all places to "parameters".

"required": true,
"type": "string",
"enum": [ "current" ],
"description": "Accounts creation setting name, now only support \"current\".",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

are you planning on adding other values? If there's only one value in the enum on a required parameter, then it's value will be taken as a constant (https://github.com/Azure/autorest/blob/master/docs/extensions/readme.md#single-value-enum-as-a-constant)
You could just write that value in the path as a constant, if you're not planning on adding more values.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This operation has been changed to POST after more discussions with ARM team. This "current" has gone.

"200": {
"description": "OK",
"schema": {
"$ref": "#/definitions/CognitiveServicesResourceKindSettingResult"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is this a pageable operation?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No.

"skuAvailable": {
"type": "string",
"description": "Indicates the given SKU is available or not.",
"enum": [
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should this be a boolean? are there other values this property may accept?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changed to Boolean.

"allowCreate": {
"type": "string",
"description": "Whether allow user to create resource.",
"enum": [
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should this be a boolean? could this property accept other values?

"allowCreate": {
"type": "string",
"description": "Whether allow user to create resource.",
"enum": [
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the suggestion from AutoRest is to evaluate if the property is really a boolean or not, the intent is to consider if there could be more than 2 values possible for the property in the future or not, if the answer is no, then a boolean is fine, if the answer is yes, there could be other values, then make it an enum with values that represent what those should be. The idea is that it can help avoid breaking changes if you want to add one more possible value, naming the values "true", "false" I believe defeats this purpose.

felixwa added 3 commits April 6, 2017 16:42
Commit original 2016-02-01-preview version for comparison purpose
Fix review comments from veronicagg
Fix a typo.
@felixwa
Copy link
Contributor Author

felixwa commented Apr 6, 2017

@veronicagg , I have commit 2016-02-01-preview version then made another commit to overwrite it with 2017-04-18 version. Let me know if this works for you.
Also I have added those missing "description" fields - it is strange that AutoRest I use locally did not report them, I'm sure I am using the latest. Does travis-ci use a different version?
As for ms-examples, I know now they should be added to a separated folder. Please help review existing changes first and if they looking good for you I can add them in this PR or a new PR (I prefer to add them in a new PR).

@veronicagg
Copy link
Contributor

@felixwa thanks for committing the previous version! Regarding the latest version of autorest, here are the update instructions for autorest: https://github.com/Azure/autorest#updating-autorest (just to make sure you're running the latest - Travis should be using the latest).
The examples (x-ms-examples) are in a separate folder, but need a reference from the swagger spec in each operation. We should do it in this PR, because it helps catch validate the swagger spec, so if there are issues, we want to fix them from the start instead of bug fixes (as this is a new api-version). Thanks!

@veronicagg
Copy link
Contributor

"in": "body",
"required": true,
"schema": {
"$ref": "#/definitions/CognitiveServicesAccountCreateParameters"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CognitiveServicesAccountCreateParameters [](start = 37, length = 40)

Is there a reason for the body parameter and the response not being the same model? Please consider this rule" "M2017: The model definition for the body parameter and the response MUST be the same for a PUT operation. This ensures that the same entity will be reusable between GET and PUT." (from https://github.com/Azure/azure-rest-api-specs/blob/62c96876795e600de8369efe42edd3a70f494017/documentation/swagger-checklist.md)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@veronicagg , we followed RPC v2. In PUT body, there is no need to put id/name/type etc. there because they are already there in URL.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@felixwa would you consider changing this in the future? Users of the api won't be able to reuse the same identity between GET and PUT ("This ensures that the same entity will be reusable between GET and PUT." ). There will be an error shown by our validation tools on this soon.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok we could consider that if the tool will report this anyway. Will that be a breaking change for RP and/or this swagger file?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be a breaking change for the SDK, so it'd need to be done consciously.

"properties": {
"sku": {
"$ref": "#/definitions/Sku",
"description": "Required. Gets or sets the SKU of the resource."
Copy link
Contributor

@veronicagg veronicagg Apr 6, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please take a look at: "M2016: For PATCH operation, every property in the model for the request body MUST be optional and the property MUST NOT provide any default value. The absence of default values applies recursively to complex properties in the model definition." (from https://github.com/Azure/azure-rest-api-specs/blob/62c96876795e600de8369efe42edd3a70f494017/documentation/swagger-checklist.md)
The description says this is required, I don't this marked as required, but the Sku model has "name" as required.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not required. I have revised the "description".

],
"description": "The SKU of the cognitive services account."
},
"CognitiveServicesAccountPropertiesCreateParameters": {
Copy link
Contributor

@veronicagg veronicagg Apr 6, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CognitiveServicesAccountPropertiesCreateParameters [](start = 5, length = 50)

is there no type for this model? object?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is just a placeholder actually. The RP SDK requires this field but we don't have any properties in it.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure I understand this, could you clarify? "properties" is also a required property, what would the user input to this property? what would you include in your example for this case?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Like below:

{
"sku":{
"name": "S0"
},
"location": "westeurope",
"kind": "Face",
"properties": {}
}

User would input nothing in the "properties" field. For our RP it is not required, it is just RP SDK requires that field present there.

},
"properties": {
"x-ms-client-flatten": true,
"$ref": "#/definitions/CognitiveServicesAccountPropertiesCreateParameters",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CognitiveServicesAccountPropertiesCreateParameters [](start = 33, length = 50)

what is this flattening? I don't see any properties in the referenced model.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removed (but AutoRest reports a new warning).

Copy link
Contributor

@veronicagg veronicagg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please see some more questions/comments inline.

1. Change account name max/min length to be consistent with UI.
2. Resolved some review comments.
3. Fix some issues with CheckSkuAvailability operation.
@felixwa
Copy link
Contributor Author

felixwa commented Apr 7, 2017

@veronicagg , I have added securityDefinitions and resolved some review comments.
I can add examples in this PR after we agree on left open ones.

Copy link
Contributor

@veronicagg veronicagg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please see reply to a couple of your comments.

Adding examples for every operation.
Fix some issues found when adding examples.
@felixwa
Copy link
Contributor Author

felixwa commented Apr 10, 2017

@veronicagg , I have added examples for every operation.

"message": {
"type": "string",
"description": "Additional error message."
}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@veronicagg , I noticed that validate-example reports warnings for these 2 fields because the in example they are null. I tried to make the type ["string", "null"] but then AutoRest reports errors then.
Please advice how to make tools happy in this case.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@felixwa you may be hitting #798, if so, please ignore the reported error for now.

@veronicagg
Copy link
Contributor

veronicagg commented Apr 10, 2017

Regarding the "properties" that I asked before, is there a reason why there is a $ref in that case and not something like?
"properties": {
"type": "object",
"additionalProperties": {
"type": "string"
},
"description": "Must exist in the request. Must not be null."
}

or even without "additionalProperties"?
Also, you may want to indicate in the description that an empty object must be sent in this case.

Remove CognitiveServicesAccountPropertiesCreateParameters, make it
"inline" and refine description.
We still need it because currently the underlying SDK requires it.
@felixwa
Copy link
Contributor Author

felixwa commented Apr 11, 2017

@veronicagg , I have removed that CognitiveServicesAccountPropertiesCreateParameters and make it "inline" as you suggested.

@veronicagg veronicagg merged commit f1786a1 into Azure:master Apr 11, 2017
@AutorestCI
Copy link

No modification for Ruby

@AutorestCI
Copy link

No modification for NodeJS

@AutorestCI
Copy link

No modification for Python

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

8 participants