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

Document values for CheckNameAvailabilityParameters.type #2967

Closed
jhendrixMSFT opened this issue Apr 27, 2018 · 1 comment · Fixed by #2969
Closed

Document values for CheckNameAvailabilityParameters.type #2967

jhendrixMSFT opened this issue Apr 27, 2018 · 1 comment · Fixed by #2969
Assignees

Comments

@jhendrixMSFT
Copy link
Member

I was playing with this API and there is no documentation on the values for this property, I ended up having to look at the example JSON to figure it out. Ideally it would be an enum but that would be a breaking change. Can the docs for this field be updated with the possible values?

@TimLovellSmith
Copy link
Member

This is similar to the corresponding api for many other resource types... Currently the only allowable value for resource type should be 'Microsoft.Cache/redis'.

TimLovellSmith added a commit to TimLovellSmith/azure-rest-api-specs that referenced this issue May 1, 2018
…zure#2968. Documenting the 'CheckNameAvailability.type' property better to address Azure#2967 (and marking properties as required). Also using a more realistic timespan value in the PatchSchedule examples.
jianghaolu pushed a commit that referenced this issue May 3, 2018
* Improve redis Swagger. Documenting 'list all patchSchedules' to fix #2968. Documenting the 'CheckNameAvailability.type' property better to address #2967 (and marking properties as required). Also using a more realistic timespan value in the PatchSchedule examples.

* Backport to the Microsoft.cache/redis 2017-10-01 swagger (from 2018-03-01).
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 a pull request may close this issue.

2 participants