Documentation on an endpoint with only String as input in RequestBody

Hi,

I try to document something like this :

@RequestMapping(value = "exists", method = RequestMethod.POST, consumes = "text/plain")
public void alreadyExist(@PathVariable UUID id, @RequestBody String email, HttpServletResponse response) {
    ...
}

and I’ve write this kind of simple test :

@Test
    public void should_verify_a_user_doesnt_exist_in_sub() throws Exception {
        String email = "[e-mail]";

        this.mockMvc
                .perform(
                        post("/api/v1/subscriptions/{id}/users/exists", "0058d39f-daac-01d7-71a4-edbdcea7c480")
                                .contentType(MediaType.TEXT_PLAIN_VALUE)
                                .accept(MediaType.ALL_VALUE)
                                .content(email)
                .andExpect(status().isNoContent())
                .andDo(document("api/v1/subscriptions/id/users/exists/post", preprocessRequest(prettyPrint()), preprocessResponse(prettyPrint()),
                        pathParameters(
                                parameterWithName("id").description("UUID of the subscription")
                        )
                ));

    }

All is ok, but I don’t find anyway to document the payload of the request. All the method to do that (Payload Documentation) is for working on an object which can be handle by Jackson, and in this case, a String is not a parseable element.

Do I misunderstand something or is it impossible to do that ?

Thanks for your help

[davinkevin]

Having the same way of generating snippet with primitive and JSON / XML could be better I think. It could generate a single line table with location (obviously, root of RequestBody), Type and Description.

And, if that is possible, if in the future the input type of the controller change (for a JSON Object for example), the RestDoc will throw a error because the object is not correctly documented.

Right now, I’ve documented directly in the Asciidoctor source, but I think it isn’t a consistent way of documenting the API, this is why I open an issue.

Thanks for your help

[wilkinsona]

Thanks for the follow up. Sounds like this discussion has run its course. We can reopen the issue if that proves not to be the case.