> +import org.jclouds.rest.annotations.PayloadParam;
> +import org.jclouds.rest.annotations.RequestFilters;
> +
> +/**
> + * Provides access to Resource features.
> + *
> + */
> +@RequestFilters(AuthenticateRequest.class)
> +@Consumes(MediaType.APPLICATION_JSON)
> +@Produces(MediaType.APPLICATION_JSON)
> +public interface TemplateApi {
> +
> + @Named("validation:validate_template")
> + @POST
> + @Path("/validate")
> + @Fallback(NullOnNotFoundOr404.class)
Fallbacks should not be used to "match" what the API specs say. They should be
used to configure "what users perceive". In this case, if the 404 is a
documented response code, we have to think about how this method will look like
to users: it is a method that returns the template when the validation
succeeds, but what should it return when the validation fails?
If we use the fallback, a `null` return value may not give enough feedback
about where the failure happened: did the validation fail? Did the request
fail? I don't know if this could be a valid case in this request. Would it make
sense to configure a different fallback that returned a more appropriate
exception? If this method is commonly used to just validate, could it return a
boolean instead?
Given your input, I don't have a strong opinion on leaving or removing the
fallback. Up to you! :) But let's keep this questions in mind to have an API
easily understandable and usable by the end users.
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs-openstack/pull/193/files#r32579338
