search

Azure / azure-resource-manager-schemas

Schemas used to author and validate Resource Manager Templates. These schemas power the intellisense and syntax completion in our ARM Tools VSCode extension, as well as the Export Template API
MIT License
611 stars 517 forks source link

Confused on Microsoft.Logic schema between version 2016-10-01 and 2017-07-01 #494

Closed ToMakeSense closed 5 years ago

ToMakeSense commented 6 years ago

After comparing the two version(2016-10-01 and 2017-07-01), there are no changes except for Id & apiVersion property, what's the purpose of adding a new version(2017-07-01) image

anthony-c-martin commented 5 years ago

The reason for an API version bump is usually to introduce a breaking change while maintaining backwards compatibility. There can be changes in service behavior between API versions that are not reflected in the schema, so you should not necessarily always expect to see a difference.

ToMakeSense commented 5 years ago

@antmarti-microsoft thanks for your clarification！I really learn a lesson from it.

ToMakeSense commented 5 years ago

@anthony-c-martin and what about this query? Azure/azure-powershell#6913

Reply from one microsoft employee

So I'm not sure what the issue is here. The version in the response for the callback URL is tied to the API version used to call the endpoint. So in the Portal the 2016-10-01 API version is being used, whereas the SDK/PowerShell cmdlet is using 2016-06-01 version.

My question based on the reply

According to my cognition, after deployment, the logic app trigger callback url(the API version) should be the static whatever tools is used to get it.

anthony-c-martin commented 4 years ago

@ToMakeSense I can't really speak for LogicApps as they own this API. Not sure if this is what you're asking about, but note that in ARM, the "API version" is not an intrinsic property of the resource. It's simply a means of requesting a view of the resource according to a certain pre-defined contract.

So as long as the API versions are defined, it's fine to mix API versions with requests like: PUT /{scope}/myresource?api-version=2016-06-01 GET /{scope}/myresource?api-version=2016-10-01 GET /{scope}/myresource?api-version=2016-06-01 DELETE /{scope}/myresource?api-version=2016-10-01

All of the above operations are acting on the same resource, and they're all perfectly valid. As I mentioned earlier, because the API version is not a property of the resource, the server should handle requests for either API version just fine. If Portal & PowerShell are using different API versions to fetch the resource, then my assumption is that the callback URL is being shaped to reflect the API version it was requested with.

If a resource is requested at version 2016-06-01, then the server cannot assume that the caller will be able to handle a response containing 2016-10-01. On the other hand if the client requests the resource at version 2016-10-01, then it seems fair to assume that the caller will be able to handle a response containing 2016-01-01. Although you're seeing different query parameters on the two URLs returned via Portal/PowerShell, I would assume that both would work if you used either of them.