SpringMVC: un resumen de la práctica del proyecto de solicitud HTTP

(1) Introducción a MIME

(1. Introducción

estructura gramatical

type/subtype         类型/独立类型

Un tipo de medio (a menudo denominado Extensiones multipropósito de correo de Internet o tipo MIME) es un estándar que se utiliza para expresar la naturaleza y el formato de un documento, archivo o flujo de bytes. Está definido y estandarizado en IETF RFC 6838.

Importante: los navegadores suelen utilizar el tipo MIME (en lugar de la extensión del archivo) para determinar cómo manejar la URL, por lo que es muy importante que el servidor web agregue el tipo MIME correcto en el encabezado de respuesta. Si la configuración es incorrecta, el navegador puede distorsionar el contenido del archivo, el sitio web no funcionará correctamente y el archivo descargado se procesará incorrectamente.

La estructura de composición de MIME es muy simple; se compone de dos cadenas separadas por una '/' entre el tipo y el subtipo. No se permiten espacios. type representa una categoría independiente que se puede dividir en varias subcategorías. subtipo representa cada tipo después de la subdivisión.

El tipo MIME no distingue entre mayúsculas y minúsculas, pero la forma tradicional de escribir es en minúsculas.

(2) Tipo independiente

text/plain
text/html
image/jpeg
image/png
audio/mpeg
audio/ogg
audio/*
video/mp4
application/*
application/json
application/javascript
application/ecmascript
application/octet-stream

Si no hay un subtipo específico para el tipo de archivo de texto, se utiliza text / plain. De manera similar, el archivo binario no tiene un subtipo específico o conocido, es decir, se usa application / octet-stream.

(2) Cuatro métodos comunes de envío de datos POST

El protocolo estipula que los datos enviados por POST deben colocarse en el cuerpo de la entidad, pero el protocolo no especifica qué método de codificación deben usar los datos. De hecho, los desarrolladores pueden decidir completamente el formato del cuerpo del mensaje por sí mismos, siempre que la última solicitud HTTP enviada cumpla con el formato anterior.

Sin embargo, para que los datos se envíen, solo tiene sentido que el servidor los analice correctamente. Los lenguajes de servidor comunes como php, python, etc., así como sus marcos, tienen funciones integradas para analizar automáticamente formatos de datos comunes. El servidor normalmente sabe cómo se codifica el cuerpo del mensaje en la solicitud de acuerdo con el campo Content-Type en los encabezados de la solicitud y luego analiza el cuerpo. Entonces, cuando se trata del esquema de envío de datos POST, incluye dos partes: el tipo de contenido y el método de codificación del cuerpo del mensaje. Comencemos a presentarlos formalmente.

[Application / x-www-form-urlencoded]
Esta debería ser la forma más común de enviar datos a través de POST. La forma nativa del navegador, si no se establece el atributo enctype, terminará con

POST http://www.example.com HTTP/1.1
Content-Type: application/x-www-form-urlencoded;charset=utf-8

title=test&sub%5B%5D=1&sub%5B%5D=2&sub%5B%5D=3

En primer lugar, el tipo de contenido se especifica como application / x-www-form-urlencoded; en segundo lugar, los datos enviados se codifican de acuerdo con key1 = val1 & key2 = val2, y tanto key como val se transcodifican en URL. La mayoría de los lenguajes del lado del servidor tienen un buen soporte para este método. Por ejemplo, en PHP, ${}_{P}OST{[}^{\prime }Titl{e}^{\text{'}}]Puede\; serparaobtenerllegaraTITLEdevalores,$_POST [' sub '] puede ser sub matriz.

Muchas veces, cuando enviamos datos con Ajax, también usamos este método. Por ejemplo, en Ajax de JQuery, el valor predeterminado de Content-Type es
"application / x-www-form-urlencoded; charset = utf-8"

[Multipart / form-data]
Esta es otra forma común de envío de datos POST. Cuando usamos el formulario para cargar archivos, el enctype del formulario debe ser igual a multipart / form-data.
[Aplicación / json]

El tipo de contenido de la aplicación / json ciertamente no es ajeno al encabezado de respuesta. De hecho, cada vez más personas lo usan como encabezado de solicitud para decirle al servidor que el cuerpo del mensaje es una cadena JSON serializada. Debido a la popularidad de la especificación JSON, todos los navegadores principales, excepto las versiones inferiores de IE, admiten JSON.stringify de forma nativa, y los lenguajes del lado del servidor también tienen funciones para procesar JSON, por lo que no encontrará ningún problema al usar JSON.

El formato JSON admite datos estructurados que son mucho más complejos que los pares clave-valor, lo que también es útil.

[Text / xml]
Es una especificación de llamada remota que utiliza HTTP como protocolo de transmisión y XML como método de codificación. Una solicitud XML-RPC típica se ve así:

POST http://www.example.com HTTP/1.1 
Content-Type: text/xml

<?xml version="1.0"?>
<methodCall>
    <methodName>examples.getStateName</methodName>
    <params>
        <param>
            <value><i4>41</i4></value>
        </param>
    </params>
</methodCall>

El protocolo XML-RPC es simple, funcional y se puede implementar en varios idiomas. También es muy utilizado, como el XML-RPC Api de WordPress, el servicio de ping de los motores de búsqueda, etc. En JavaScript, también hay bibliotecas listas para usar que admiten la interacción de datos de esta manera, que pueden admitir los servicios XML-RPC existentes. Sin embargo, personalmente creo que la estructura XML todavía está demasiado inflada y es más flexible y conveniente usar JSON en escenarios generales.

(3) Cómo SpringMVC recibe solicitudes POST

(1) Tipo de contenido predeterminado

El tipo de contenido se transmite en application / x-www-form-urlencoded, el formulario predeterminado.
Este método de transmisión consiste en construir la solicitud posterior normal del formulario para la transmisión
. Se requieren dos parámetros en el controlador. Al mismo tiempo, tenga en cuenta que esto no se puede agregar @RequestBody De lo contrario, se lanzará una excepción 405 y los parámetros se completarán en los parámetros en forma de cadenas y matrices

método de recepción application / x-www-form-urlencoded:

1 ： @RequestParam ("nombre")

2: use la misma cadena de nombre de clave para recibir el nombre de cadena, el nombre debe coincidir

3: use la clase de entidad para recibir, el atributo coincidente inyectará el valor, se requiere el método setgeter y el nombre es inconsistente y no se puede inyectar

4: Use request.getParameter ("nombre"); para recibir

（2） aplicación / json

Content-Type se transmite en forma de application / json. De
esta manera, se debe transmitir una cadena de formato json. El
controlador debe usar una cadena para aceptar la cadena json.
Si se usan anotaciones, se debe agregar @RequestBody
. Lea el contenido del cuerpo en el campo de solicitud y luego deserialice esta cadena en json en un objeto. Si desea que se convierta automáticamente en un objeto, debe configurar la herramienta de serialización json en la configuración de SpringMVC.

El método de referencia es el siguiente:

1: use @RequestBody String para recibir, directamente a una cadena que no se puede recibir, de esta manera recibe una cadena JSON, debe convertirla usted mismo

2: @RequestBody más recepción POJO o cadena

3: @RequestBody Map <String, Object> json, es más conveniente usar Map para recibir, no es necesario construir un objeto VO

4: Obtenga manualmente getReader () o getInputStream () de la secuencia. Tenga en cuenta que la capa inferior del método anterior también se recibe de esta manera, y la secuencia no se puede repetir

Recibir parámetros: un objeto con múltiples atributos únicos

(4) La diferencia entre getParameter () getInputStream () y getReader ()

request.getParameter ()
request.getInputStream ()
request.getReader ()
Todos estos tres métodos obtienen los datos enviados del objeto de solicitud, pero tienen diferentes usos.

Elija diferentes métodos de acuerdo con el método de codificación de los datos de envío del formulario.

Un enctype de atributo clave del formulario en HTML:

(1) Enctype = application / x-www-form-urlencoded
Este método de codificación es el método de codificación predeterminado.
El resultado codificado suele tener el formato field1 = value2 & field2 = value2 & ..., como name = aaaa & password = bbbb.
Los formularios de uso común también se codifican de esta manera. La API de Servlet proporciona soporte para la decodificación de este método de codificación. Solo necesita llamar al método getParameter () en la clase ServletRequest para obtener los campos y datos en el formulario de usuario.
Desventajas:
aunque este método de codificación (application / x-www-form-urlencoded) es simple, no es capaz de transmitir grandes bloques de datos binarios.

(2) Datos de formulario / multiparte
Para datos como grandes bloques de números binarios, el navegador utiliza otro método de codificación, a saber, el método de codificación "datos de formulario / multiparte":

El navegador puede enviar fácilmente los datos y archivos en el formulario juntos. Este método de codificación primero define una cadena que no puede aparecer en los datos como un delimitador, y luego la usa para separar cada segmento de datos, y cada segmento de datos corresponde a un área de entrada en el formulario de página HTML, incluido uno. El atributo de disposición de contenido indica algo de información de este segmento de datos. Si el contenido del segmento de datos es un archivo, también habrá un atributo de tipo de contenido, y luego los datos en sí. Si envía datos de esta manera, debe usar request.getInputStream ( ) o request.getReader () para obtener los datos enviados, el uso de request.getParameter () no puede obtener los datos enviados.

Los tres métodos request.getParameter (), request.getInputStream () y request.getReader () están en conflicto, porque la transmisión solo se puede leer una vez.
Por ejemplo:
cuando el contenido del formulario está codificado con enctype = application / x-www-form-urlencoded, los parámetros se obtienen llamando al método request.getParameter (), y luego request.getInputStream () o request.getReader () es ya no está disponible. Al contenido de la secuencia, porque el sistema puede leer los datos enviados en el formulario una vez en forma de secuencia cuando se llama a request.getParameter (), y viceversa.

Cuando el contenido del formulario está codificado con enctype = multipart / form-data, no se pueden obtener datos incluso si se llama primero a request.getParameter (), por lo que se llama al método request.getParameter () para request.getInputStream () o request. getReader ().) No hay conflicto, incluso si se ha llamado al método request.getParameter (), los datos en el formulario se pueden obtener llamando request.getInputStream () o request.getReader (), y request.getInputStream ( ) y request.getReader () están en el mismo La respuesta no se puede mezclar, y si se mezcla, se lanzará una excepción.

En la solicitud http, hay encabezado y cuerpo. Para leer el encabezado, use request.getHeader ("..."); para leer el cuerpo, use request.getReader (), pero getReader obtiene un BufferedReader, que debe ser convertido en una cadena.

 private static String getPostData(HttpServletRequest request) throws IOException {
    
    
     StringBuilder data = new StringBuilder();
     String line;
     BufferedReader reader;
     try {
    
    
         reader = request.getReader();
         while (null != (line = reader.readLine())) {
    
    
             data.append(line);
         }
     } catch (IOException ignored) {
    
    
         throw new IOException();
     }
     return data.toString();
 }

referencia

https://imququ.com/post/four-ways-to-post-data-in-http.html

https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Basics_of_HTTP/MIME_types