Документирование ответа byte [] в Spring Rest Docs

Я создаю API и документирую его с помощью Spring Rest Docs (1.1.1.RELEASE), и есть api, который возвращает изображение в виде байтового массива.

Мне нужно описать тип ответа в документах REST. Я не уверен, как это можно сделать с помощью FieldDescriptor

Когда я пытаюсь:

//get mock byte array
byte[] attachment = "Hello".getBytes();

FieldDescriptor[] contentFields = new FieldDescriptor[] {
            fieldWithPath("").type(byte[].class)
                    .description("bytes of the attachment ")};

    when(serviceMock.getImage("fe329638007b4ea3b2a5")).thenReturn(attachment);

    this.mockMvc
            .perform(RestDocumentationRequestBuilders.get("/api/v1/contents/{contentId}/images", "fe329638007b4ea3b2a5"))
            .andExpect(status().isOk()).andDo(document("{method-name}",
                    pathParameters(parameterWithName("contentId").description("The id of the Content")),
                    responseFields(contentFields)));

    verify(serviceMock, times(1)).getImage("fe329638007b4ea3b2a5");
    verifyNoMoreInteractions(serviceMock);

Я получаю ошибку ниже

org.springframework.restdocs.payload.PayloadHandlingException: com.fasterxml.jackson.core.JsonParseException: Unrecognized token 'Hello': was expecting ('true', 'false' or 'null')
 at [Source: [B@13866865; line: 1, column: 11]
at org.springframework.restdocs.payload.JsonContentHandler.readContent(JsonContentHandler.java:86)
at org.springframework.restdocs.payload.JsonContentHandler.findMissingFields(JsonContentHandler.java:52)
at org.springframework.restdocs.payload.AbstractFieldsSnippet.validateFieldDocumentation(AbstractFieldsSnippet.java:152)
at org.springframework.restdocs.payload.AbstractFieldsSnippet.createModel(AbstractFieldsSnippet.java:100)
at org.springframework.restdocs.snippet.TemplatedSnippet.document(TemplatedSnippet.java:64)
at org.springframework.restdocs.generate.RestDocumentationGenerator.handle(RestDocumentationGenerator.java:196)
at org.springframework.restdocs.mockmvc.RestDocumentationResultHandler.handle(RestDocumentationResultHandler.java:55)
at org.springframework.test.web.servlet.MockMvc$1.andDo(MockMvc.java:177)
at com.davita.comms.controller.CommsControllerTest.getThumbnailByContentId(CommsControllerTest.java:205)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.springframework.test.context.junit4.statements.RunBeforeTestMethodCallbacks.evaluate(RunBeforeTestMethodCallbacks.java:75)
at org.springframework.test.context.junit4.statements.RunAfterTestMethodCallbacks.evaluate(RunAfterTestMethodCallbacks.java:86)
at org.springframework.restdocs.JUnitRestDocumentation$1.evaluate(JUnitRestDocumentation.java:55)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.springframework.test.context.junit4.statements.SpringRepeat.evaluate(SpringRepeat.java:84)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:252)
at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:94)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.springframework.test.context.junit4.statements.RunBeforeTestClassCallbacks.evaluate(RunBeforeTestClassCallbacks.java:61)
at org.springframework.test.context.junit4.statements.RunAfterTestClassCallbacks.evaluate(RunAfterTestClassCallbacks.java:70)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:191)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:670)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)

Есть ли способ указать в FieldDescriptor, что возвращаемые данные не являются json, поэтому нет смысла указывать путь.

Есть ли другой способ задокументировать это без FieldDescriptors?


spring spring-mvc spring-test spring-rest spring-restdocs
person Tatha    schedule 30.08.2016    source источник

Ответы (1)


arrow_upward
7
arrow_downward

REST Docs не поддерживает документирование содержимого двоичных полезных данных. Фрагменты полей запроса и ответа предназначены для документирования структуры полезной нагрузки JSON или XML.

Я не думаю, что вы получите много пользы от использования REST Docs для создания таблицы, описывающей ваш двоичный ответ, поскольку здесь нечего утверждать. Любой ответ можно рассматривать как byte [], поскольку это ответ в его наиболее необработанной форме. Например, JSON - это байт [], как и XML. Это просто байтовые массивы с определенными ограничениями на их содержимое.

Вместо того, чтобы пытаться использовать REST Docs для создания таблицы для описания двоичного ответа, я бы просто жестко закодировал ее в вашем .adoc файле. Если вы хотите включить в свой тест некоторые утверждения о содержимом ответа, я бы использовал некоторые сопоставители MockMvc. Например, вы можете утверждать, что тело ответа совпадает с байтами, которые вы настроили для возврата фиктивной службы.

person Andy Wilkinson    schedule 30.08.2016
comment
Спасибо, Энди !! Вот чем я сейчас занимаюсь. Я добавлю тип ответа в .adoc - person Tatha; 30.08.2016
comment
Я предпочитаю добавлять метод сниппета responseBody () вместо того, чтобы писать в adoc. Ответ может быть строкой, выражающей токен, может быть изображением, текстом и т. Д. - person Fırat KÜÇÜK; 21.11.2016
comment
Ответы с жестким кодированием (или тело запроса) в adoc действительно добавляют необходимости, чтобы он выглядел так же, как сгенерированная таблица фрагментов описания тела. Например, я хотел бы задокументировать тело запроса POST с типом содержимого text/uri-list при связывании двух ресурсов. Просто сделайте так, чтобы отметить множественность URL-адресов в теле сообщения, было бы полезно. Мне нравится иметь согласованно выглядящую документацию. - person Lubo; 07.04.2020