method - JSON vs Form POST

javascript form fields to json

Question

Estamos teniendo un poco de debate sobre el tema de la publicación de datos en un punto final REST. Dado que los objetos son bastante complejos, la solución más fácil es simplemente serializarlos como JSON y enviarlos en el cuerpo de la solicitud.

Ahora la pregunta es esta: ¿esto es kosher? ¿O debería JSON configurarse como un parámetro de formulario como data = [JSON]? ¿O está el envío de JSON en el cuerpo de la solicitud desaprobado por forzar a los clientes que usan la aplicación, a enviar sus datos a través de JavaScript en lugar de dejar que el navegador lo empaquete como application/x-www-form-urlencoded ?

Sé que las tres opciones funcionan . Pero, ¿están bien ? ¿O al menos recomendado ?

Answer 1

Diría que ambos métodos funcionarán bien, es importante que te mantengas constante en todas tus API. La opción que elegiría personalmente es simplemente enviar el contenido como application/json .

POST no lo obliga a utilizar application/x-www-form-urlencoded ; simplemente es algo que se usa mucho porque es lo que utilizan los application/x-www-form-urlencoded .

Answer 2

No hay nada de malo en enviarlo directamente como JSON serializado, por ejemplo, google lo hace de forma predeterminada en su biblioteca de volley (que obviamente es su biblioteca REST recomendada para Android).

De hecho, hay muchas preguntas sobre SO sobre cómo no usar JSON, sino más bien realizar solicitudes POST "normales" con volley. Lo cual es un poco contrario a la intuición para principiantes, teniendo que sobreescribir el método getParams() clase base.

Pero google teniendo su propia biblioteca REST haciendo esto por defecto, sería mi indicador de que está bien .

Answer 3

Puede usar JSON como parte de los datos de solicitud, ya que el OP había declarado que las tres opciones funcionan.

El OP necesita admitir la entrada JSON ya que tenía que admitir contenido estructural complejo. Sin embargo, piense de esta manera ... ¿está haciendo una solicitud para hacer algo o simplemente está enviando lo que básicamente es información de documentos y simplemente usa la operación POST como el equivalente de crear una nueva entrada.

Siendo ese el caso, lo que tienes es básicamente un punto final de recursos con semántica CRUDL. Siguiendo con eso, en realidad no estás limitado a la application/json sino a cualquier tipo que se suponga que maneje el punto final del recurso.

Para puntos finales sin recursos

Encuentro que (específicamente para JAX-RS) la application/x-www-urlencoded es mejor.

1. Consistencia con OAuth 2.0 y OpenID Connect, usan application/x-www-urlencoded .
2. Es más fácil anotar los campos individuales usando Swagger Annotations
3. Swagger proporciona más valores predeterminados.
4. Cartero genera un buen formulario para que llene y hace las cosas más fáciles de probar.

Ejemplos de puntos finales sin recursos:

• Autenticación
• Autorización
• Búsqueda simple (aunque usaría GET en este)
• Búsqueda no simple donde hay muchos criterios
• Enviar un mensaje / documento (aunque también consideraría multipart/form-data para poder pasar metadatos junto con el contenido, pero JAX-RS no tiene un estándar para este Jersey y RestEasy tiene sus propias implementaciones)