REST - Publicación HTTP de varias partes con JSON


88

Necesito recibir un HTTP Post Multipart que contiene solo 2 parámetros:

  • Una cadena JSON
  • Un archivo binario

¿Cuál es la forma correcta de configurar el cuerpo? Voy a probar la llamada HTTP usando la consola REST de Chrome, así que me pregunto si la solución correcta es establecer una clave de "etiqueta" para el parámetro JSON y el archivo binario.

En el lado del servidor estoy usando Resteasy 2.x, y voy a leer el cuerpo de Multipartes así:

@POST
@Consumes("multipart/form-data")
public String postWithPhoto(MultipartFormDataInput  multiPart) {
  Map <String, List<InputPart>> params = multiPart.getFormDataMap();
  String myJson = params.get("myJsonName").get(0).getBodyAsString();
  InputPart imagePart = params.get("photo").get(0);
  //do whatever I need to do with my json and my photo
}

¿Es este el camino a seguir? ¿Es correcto recuperar mi cadena JSON usando la clave "myJsonName" que identifica esa disposición de contenido en particular? ¿Hay alguna otra forma de recibir estos 2 contenidos en una solicitud HTTP de varias partes?

Gracias por adelantado


1
¿Qué tipo de recurso REST es este? ¿Cómo se relacionan dos partes a nivel de recursos?

En realidad, la forma en que manejamos este recurso no es totalmente RESTful porque la imagen es un "componente" del recurso en lugar de otro recurso.
thermz

Respuestas:


148

Si lo entiendo correctamente, desea redactar una solicitud de varias partes manualmente desde una consola HTTP / REST. El formato de varias partes es simple; se puede encontrar una breve introducción en la especificación HTML 4.01 . Necesita crear un límite, que es una cadena que no se encuentra en el contenido, digamos HereGoes. Establece el encabezado de la solicitud Content-Type: multipart/form-data; boundary=HereGoes. Entonces este debería ser un cuerpo de solicitud válido:

--HereGoes
Content-Disposition: form-data; name="myJsonString"
Content-Type: application/json

{"foo": "bar"}
--HereGoes
Content-Disposition: form-data; name="photo"
Content-Type: image/jpeg
Content-Transfer-Encoding: base64

<...JPEG content in base64...>
--HereGoes--

De hecho, también puede agregar un archivo adjunto en soap-ui. Esto alivia tener que pasar el cuerpo de la publicación real y el tipo de contenido.
shane lee

1
¿Existe una forma estandarizada de establecer el límite único?
andig

2
@andig No tengo conocimiento de ninguno. Quizás podría usar un UUID , pero eso no es necesariamente una buena idea. Normalmente, su biblioteca HTTP debería encargarse de eso por usted.
Vasiliy Faronov

Si sabemos que solo tenemos datos json y base64 en la solicitud, ¿no debería funcionar algo como, \*por ejemplo, como un límite? No se permite que exista en json ni en base64.
DaedalusAlpha

2
¿Por qué utilizar base64 para codificar los datos JPEG? HTTP le permite enviar los bytes sin procesar.
Alexandre Blin
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.