Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Merged
merged 18 commits into from
Feb 11, 2017
Merged

Conversation

naveedaz
Copy link
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
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
Contributor Author

Fixed the folder structure.

@@ -207,76 +271,6 @@
}
}
},
"/subscriptions/{subscriptionId}/providers/Microsoft.Web/publishingCredentials": {
Copy link
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
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
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
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
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
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
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
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

@AutorestCI
Copy link

@AutorestCI
Copy link

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