> + @Named("sharedstorages:servers:create")
> + @POST
> + @Path("/{sharedStorageId}/servers")
> + SharedStorage attachServer(@PathParam("sharedStorageId") String
> sharedStorageId, @BinderParam(BindToJsonPayload.class) Server.CreateServer
> server);
> +
> + @Named("sharedstorages:servers:get")
> + @GET
> + @Path("/{sharedStorageId}/servers/{serverId}")
> + @Fallback(Fallbacks.NullOnNotFoundOr404.class)
> + Server getServer(@PathParam("sharedStorageId") String sharedStorageId,
> @PathParam("serverId") String serverId);
> +
> + @Named("sharedstorages:servers:delete")
> + @DELETE
> + @Path("/{sharedStorageId}/servers/{serverId}")
> + @MapBinder(BindToJsonPayload.class)
> + @Fallback(Fallbacks.NullOnNotFoundOr404.class)
Hmmmm I'm not sure about the convenience of this fallback here, as it could be
ambiguous. We're not actually deleting something that may not exist, but
detaching a resource from one that *should* exist, otherwise the detach
operation makes no sense. I'd remove the fallback to let the method propagate
an exception on a 404. IMO that would be the less ambiguous feedback for users
upon failure. WDYT?
---
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/304/files/b4ecd2bdfe26ff68d6dd6c9e03a4de2e3eba3fe2#r72953270
