Retrofit: allow empty @PUT annotation without the @Url first parameter requirement

[colesnodgrass]

From the @PUT documentation

A relative or absolute path, or full URL of the endpoint. This value is optional if the first parameter of the method is annotated with @Url.

Which means a PUT request directly against the base-url is not currently possible.

An example:

// in a real-world example the url would be read in from a configuration file
Retrofit adapter = new Retrofit.Builder().baseUrl("https://example/v1/").build()

This is not currently supported:

public interface ExampleApi {    
    @PUT
    Call<Void> save(@Body ExampleBody body);
}

It will fail with a java.lang.IllegalArgumentException: Missing either @PUT URL or @Url parameter. exception.

I can't think of a valid reason for this limitation and have discovered a temporary workaround that bypasses it:

public interface ExampleApi {    
    @PUT(" ")
    Call<Void> save(@Body ExampleBody body);
}

In this situation, I don't have a dynamic URL and don't need to specify it per request, I will always be executing the PUT against the base-url. This workaround feels like a hack and it would be preferred if the @PUT annotation value was always optional.

[JakeWharton]

You can actually use ./ for this. I like for two reasons, actually:

• It prevents any case where the absence of a relative path or @Url which makes the logic unambiguous and without special cases.
• It serves as explicit intent that you want to use the path of the base URL and add nothing to it.

[SuhailMirjiDCMCompliance]

@JakeWharton My request is jumping to onFailure . If i use "./" for the GET request to access the base URL.

[tomasbartalos]

@JakeWharton Same here, with '@GET("./")' it fails with:
java.io.EOFException: End of input at line 1 column 1 path $

[alan-givati]

The solution Jake offered may work but it seems unnecessarily verbose.
@POST("./") is no where near as clean and concise as just @POST, @PATCH, etc.
Adding a default of "./" would be useful. An option to choose a default value for all method specifier annotations would be best - let it be ambiguous for those of us not bothered by that potential issue.

[imrobertloucans]

Is it possible to omit the trailing "/" as well - I have a server that exposes https://something/api/a - but does not respond to https://something/api/a/