az rest response code

[jurgyy]

Is your feature request related to a problem? Please describe.
Currently when making put or patch requests using az rest it can be unclear whether the request is executed successfully. Unsuccessful execution returns an error, but there are certain commands that have multiple successful responses such as api create/update: codes 200, 201 and 202. In this case getting no returned value is confusing as to what has happened.

Describe the solution you'd like
It would be nice if az rest was able to return those codes to ease the flow of scripts.

Describe alternatives you've considered
In the current scenario I have to send a get request to check if everything is set as expected while this information is (sometimes) already present in the response header so perhaps return the header entirely.

[maggiepint]

Hi,
I've routed this to the appropriate team for follow-up.

[mattgwic]

It should at least show up when I use --debug

[jurgyy]

Any update on this?

I've just spend the past hour debugging a problem with trying to create an API and the source of the problem was that in the Swagger specification the property properties.value.info.title was identical to an already existing API. Sending the request manually I got a 202 Accepted response with a location url in the header which when I send a GET request I received the following message:

{
	"error": {
		"code": "ValidationError",
		"message": "One or more fields contain incorrect values:",
		"details": [{
				"code": "ValidationError",
				"target": "name",
				"message": "API with specified name 'myApiName' already exists"
			}
		]
	}
}

Would've been nice if az rest returns something along those lines...

e: note that az rest returned no response or anything. Running it with --debug ended with az_command_data_logger : exit code: 0 so not useful at all.

[zhoxing-ms]

This issue is related to asynchronous operation, asynchronous execution will be adopted for some time-consuming operations.
Usage documents of asynchronous API: link

[zhoxing-ms]

@jurgyy What do you expect to return? Is the location URL returned when you manually request to create the API or the ValidationError returned when you send a GET request for the second time?

[jurgyy]

@zhoxing-ms Due to the asynchronous nature of the problem I'd suppose the location URL would suffice and let the end user decide what to do with it. But not returning anything is undesired behavior in my opinion.

[zhoxing-ms]

@jurgyy OK, I will submit a PR to fix it. After that, you can get information about the header by using --debug, such as the location URL.

[jiasli]

We have changed the behavior in PR #12117 for --verbose log (including --debug) to show more information as other commands do (like az group show --debug).

Request URL: 'https://management.azure.com/subscriptions/0b1f6471-1bf0-4dda-aec3-cb9272f09590/resourcegroups/myrg?api-version=2019-07-01'
Request method: 'GET'
Request headers:
    'User-Agent': 'AZURECLI/2.2.0'
    'Accept-Encoding': 'gzip, deflate'
    'Accept': '*/*'
    ...
Request body:
None
Response status: 200
Response headers:
    'Cache-Control': 'no-cache'
    'Pragma': 'no-cache'
    'Content-Type': 'application/json; charset=utf-8'
    'Content-Encoding': 'gzip'
    ...
Response content:
{"id":"/subscriptions/0b1f6...

For including raw http information in the response body from stdout, I have a proposal at #12117 (comment). It would be great if anyone can share some suggestions. 😃