Document the Api Schema Contract#1801
Conversation
|
@ravbhatnagar FYI |
| "tags": [ | ||
| "ApiSchema" | ||
| ], | ||
| "operationId": "ApiSchema_CreateOrUpdate", |
There was a problem hiding this comment.
Example missing for this operation.
| "ProductArray": { | ||
| "type": "array", | ||
| "items": { | ||
| "$ref": "#/definitions/Product" |
There was a problem hiding this comment.
That is just a Schema. It will differ from Api to API. I will update the example with a WSDL Api Schema, so that the tooling doesn't get confused.
| "PriceEstimateArray": { | ||
| "type": "array", | ||
| "items": { | ||
| "$ref": "#/definitions/PriceEstimate" |
There was a problem hiding this comment.
That is just a Schema. It will differ from Api to API. I will update the example with a WSDL Api Schema, so that the tooling doesn't get confused.
| "tags": [ | ||
| "ApiSchema" | ||
| ], | ||
| "operationId": "ApiSchema_ListByApi", |
There was a problem hiding this comment.
Since this operation returns pageable results I believe you need to annotate it with the x-ms-pageable extension. See here for more information.
|
Hi There, I am the AutoRest Linter Azure bot. I am here to help. My task is to analyze the situation from the AutoRest linter perspective. Please review the below analysis result: File: AutoRest Linter Guidelines | AutoRest Linter Issues | Send feedback Thanks for your co-operation. |
|
Hi There, I am the AutoRest Linter Azure bot. I am here to help. My task is to analyze the situation from the AutoRest linter perspective. Please review the below analysis result: File: AutoRest Linter Guidelines | AutoRest Linter Issues | Send feedback Thanks for your co-operation. |
ravbhatnagar
left a comment
There was a problem hiding this comment.
Looks fine. A few minor notes/questions
| "description": "Schema Contract details." | ||
| }, | ||
| "SchemaContractProperties": { | ||
| "properties": { |
There was a problem hiding this comment.
provisioningState property missing? DO you need it? Just wanted to check since you are returning 201. But its not long running so its not required. But still checking.
There was a problem hiding this comment.
This is again a proxy resource in ARM. I guess we dont need the provisioningState property.
In reply to: 143310129 [](ancestors = 143310129)
There was a problem hiding this comment.
Again, I think we should have a call and clarify a few things around tracked and non-tracked :). If it is long running operation, and you are returning 201 for the LRO, you will need to add a provisioning state property. Is it LRO?
There was a problem hiding this comment.
This is not a LRO.
| "type": "string", | ||
| "description": "Must be a valid a media type used in a Content-Type header as defined in the RFC 2616. Media type of the schema document (e.g. application/json, application/xml)." | ||
| }, | ||
| "document": { |
There was a problem hiding this comment.
Is there a upper limit on the size of this?
There was a problem hiding this comment.
| "$ref": "./apimanagement.json#/parameters/SubscriptionIdParameter" | ||
| } | ||
| ], | ||
| "responses": { |
There was a problem hiding this comment.
Also add a 200 OK response.
There was a problem hiding this comment.
We only return a 204 on Delete. This is an untracked resource in ARM.
In reply to: 143310351 [](ancestors = 143310351)
There was a problem hiding this comment.
@solankisamir - being untracked or tracked has no bearing on this. 200 on a DELETE should be the response code returned to the customers if the resource was successfully deleted. 204OK is fine to return when the requested resource was not found but the URI was well formed. This is as per the RPC and applies to both tracked and untracked resource.
There was a problem hiding this comment.
As per https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.7 if the response does not return entity then 204 is expected. We don't return entity on DELETE.
There was a problem hiding this comment.
@solankisamir - Yes, I am aware of that and it is one place where ARM recommendation slightly different. But as per RPC, the recommendation is as follows -
"The resource provider can return 200 (OK) or 204 (NoContent) to indicate that the operation completed successfully. A 200 (OK) should be returned if the object exists and was deleted successfully; and a 204 (NoContent) should be used if the resource does not exist and the request is well formed."
https://github.com/Azure/azure-resource-manager-rpc/blob/master/v1.0/resource-api-reference.md#delete-resource
It will work and everything as you have it now, but for consistency across the azure platform, I think this should be fixed.
There was a problem hiding this comment.
@ravbhatnagar we don't return 200 for any of our DELETE currently on this and it's parent entity and we have this behavior documented. We believe we can do this consistently across all entities with a new api-version, as it could be breaking change for some customers who have already taken dependency. What do you suggest?
There was a problem hiding this comment.
@solankisamir Presumably this has been the behavior for some time, so with that in mind IMO fixing this in a new API version is the correct way to go. @ravbhatnagar are you ok with that?
There was a problem hiding this comment.
Yes, I have opened a github issue tracking this #1847
| } | ||
| } | ||
| }, | ||
| "/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.ApiManagement/service/{serviceName}/apis/{apiId}/schemas": { |
There was a problem hiding this comment.
Is schemas a tracked or a untracked resource. If tracked PATCH would be needed. But I am guessing this is untracked resource. Please confirm
There was a problem hiding this comment.
|
Looks good from SDK perspective. Once we have ARM sign-off we can merge. |
|
@ravbhatnagar let me know if you have any questions. We are waiting on your sign-off. |
|
@solankisamir - left some comments |
|
No modification for AutorestCI/azure-sdk-for-python |
|
No modification for AutorestCI/azure-sdk-for-node |
|
No modification for AutorestCI/azure-sdk-for-ruby |
Based on issue #1776
PR information
api-versionin the path should match theapi-versionin the spec).Quality of Swagger