Skip to content

Removed the publishingcredentials API and re-added the publishingUsers API#925

Merged
yugangw-msft merged 18 commits intoAzure:masterfrom
naveedaz:master
Feb 11, 2017
Merged

Removed the publishingcredentials API and re-added the publishingUsers API#925
yugangw-msft merged 18 commits intoAzure:masterfrom
naveedaz:master

Conversation

@naveedaz
Copy link
Copy Markdown
Contributor

@naveedaz naveedaz commented Feb 10, 2017

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

  • I have read the contribution guidelines.
  • My spec meets the review criteria:
    • The spec conforms to the Swagger 2.0 specification.
    • Validation errors from the Linter extension for VS Code have all been fixed for this spec. (Note: for large, previously checked in specs, there will likely be many errors shown. Please contact our team so we can set a timeframe for fixing these errors if your PR is not going to address them).
    • The spec follows the patterns described in the Swagger good patterns document unless the service API makes this impossible.

@olydis
Copy link
Copy Markdown
Contributor

olydis commented Feb 10, 2017

Please adjust all arm-web folders to adhere to our new convention regarding folder structure: Swagger files should go into a swagger folder, examples go into an examples folder. See https://github.com/Azure/azure-rest-api-specs/tree/master/arm-redis/2016-04-01 for reference. Our CI tools will enforce this structure soon.

@naveedaz
Copy link
Copy Markdown
Contributor Author

Fixed the folder structure.

}
}
},
"/subscriptions/{subscriptionId}/providers/Microsoft.Web/publishingCredentials": {
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

this would be a breaking change. You are removing the API from the same api-version. When the new SDKs will be published, you would leave the customers high and dry.

/cc @johanste @lmazuel

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Intentional. This API is not per ARM spec and ARM does not let it through. So its not breaking anyone.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

@salameer @ravbhatnagar - what is the ARM guideline for removing an API from an existing api-version ?

Copy link
Copy Markdown
Contributor Author

@naveedaz naveedaz Feb 10, 2017

Choose a reason for hiding this comment

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

FYI: The resourceType 'publishingcredentials' is not in the ARM manifest for Microsoft.Web. So this is not an API that anyone can actually call into.
Here is the url.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Ah I see. I remember seeing an issue posted by a node sdk customer. Azure/azure-sdk-for-node#1909 (comment) . Ruslan recommended using this GET /providers/Microsoft.Web/publishingUsers/web?api-version=2015-08-01 instead.
Btw, is the above api present for the new api-version (Just confirming)?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Not yet. These APIs need to be redesigned properly.

],
"parameters": [
{
"name": "requestMessage",
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

If the parameter is named "userDetails" then this would be better. It gives better developer experience.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Fixed.

@AutorestCI
Copy link
Copy Markdown

@AutorestCI
Copy link
Copy Markdown

@AutorestCI
Copy link
Copy Markdown

No modification for NodeJS

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.

6 participants