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.