> + @Fallback(NullOnNotFoundOr404.class)
> + @Nullable
> + ResourceGroup get(@PathParam("name") String name);
> +
> + @Named("resourcegroup:update")
> + @PATCH
> + @Produces(MediaType.APPLICATION_JSON)
> + @Path("resourcegroups/{name}")
> + @Fallback(NullOnNotFoundOr404.class)
> + @Nullable
> + @MapBinder(BindToJsonPayload.class)
> + ResourceGroup update(@PathParam("name") String name,
> @PayloadParam("tags")Map<String, String> tags);
> +
> + @Named("resourcegroup:delete")
> + @DELETE
> + @ResponseParser(StatusCodeParser.class)
I see, in that case, I think it should be better to return something that
already allow users to track the status. What about:
* Changing the method to return a URI.
* Change (and rename) the response parser so it:
* Returns `null` if the operation succeeds and there is no task to track
(response code 200).
* Returns an URI object if there is an ongoing task (202 response code) so
users can track it.
* Propagates an exception otherwise.
This would facilitate tracking of ongoing jobs. Then we could also add a
generic method to the root `AzureApi` (or create a JobApi or whatever) like:
```java
@ResponseParser(ParseJobStatus.class)
JobStatus jobDone(URI jobURI);
```
Where `JobStatus` could be a custom enum with `DONE, IN_PRORGESS, FAILED`
states, and the response parser could return an appropriate value depending on
the response code (200, 202, others).
This would help users keep track of async requests, and also will facilitate
the implementation of the ComputeService if it needs to use such calls. WDYT
@ritazh?
---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs/pull/250/files/f7cc1b437f11378e105bba552e3cfee9d7491872#r58352801
