Feda /dev/ - No Javascript allowed

#55620 Si es un POST que recibe el server, el 3 caso es incorrecto, hay algún error de modelado.

Un cliente nunca manda un null.

#55621Kaledros:

Que cualquier deserializador te pondría myNumber a null en cuanto mapeara el JSON a objeto de dominio en el segundo y tercer caso

Si un deserializador te pone myNumber a null en el segundo caso está mal. Deberías tener un custom deserializer que te ponga el valor por defecto, 0.

Pero vamos, habría que ver el problema concreto que están tratando de resolver. Lo que está claro es que el cliente mandando un null hay un error de diseño en la API.

#55624 Como siempre digo hay que distinguir dos niveles, el de network y aplicacion.

Si a ti te llega un payload, conjunto de paquetes TCP, que se serializa a un json válido en este caso, se asume que la transmisión por TCP por network ha sido correcto. Por tanto, la llamada cliente => (...) => servidor ha sido un éxito.

Ahora, si network ha sido un éxito, estamos a nivel de aplicación, y aquí es un contrato de la API entre el cliente y el servidor que decide el modelado del json. Es decir deciden los humanos y se ponen de acuerdo en su significado. En cualquier caso, mandar nulls de cliente a servidor es un sin sentido. Incluso en casos complejos donde haya campos que se puedan activar y desactivar y además tomar valores, como un configMap, si el cliente lo quiere desactivar tendria sentido mandar un {} o tener un campo bool enabled/disabled.

Si un cliente manda una payload " " y esto no es un valid json para tu server puedes devolver un 400, y obligar al cliente que como minimo te mande un {}. Y si te refieres al caso de myNumber, una string vacia obviamente sería una bad request.

#55625

En cualquier caso, mandar nulls de cliente a servidor es un sin sentido. Incluso en casos complejos donde haya campos que se puedan activar y desactivar y además tomar valores, como un configMap, si el cliente lo quiere desactivar tendria sentido mandar un {} o tener un campo bool enabled/disabled.

Mandar un null puede tener sentido, el problema es que de normal no se puede mandar un null en muchas librerías, así que se manda " ", es más, Laravel tiene un middleware por defeccto que transforma eso en null. Si le mandas un json vacio, el asume que es un json vacio...si le mandas " ", el asume que es un null.

Yo por ejemplo lo uso para "vaciar" selects. Si no me mandas un campo asumo que lo dejas como esta, si me lo mandas vacio asumo que quieres dejar dicho campo vacio. Como obviamente no puedo mandar null en un select, pues se manda el valor " "

#55628 MyNumber = null no es lo mismo a que MyNumber no este.

Como te he dicho, en mi gestor yo asumo que si me mandas un campo en null...es que lo quieres dejar en blanco, y si dicho campo no esta, quieres dejarlo como estuviera

Y el servidor sabe que "myNumber = null"

El servidor sabe que ese campo no esta. Que tu luego por detrás quieras asumir que su no existencia significa que vale null es otra cosa.

#55630 Es decir, tu plan es que triplique el codigo en vez de hacer un codigo que funcione para absolutamente todos los casos de uso?

Si en una misma petición tengo para crear y editar objectos me invento otra palabra? Hago 2 peticiones una PUT y otra POST?

#55632

Se llama protocolo HTTP y tienes unas normas y reglas.

Si, que tu mismo has decidido inventarte.

Estas para empezar confundiendo los POST con los PUT, POST crear recurso, PUT actualizar recurso.

The PUT method requests that the enclosed entity be stored under the supplied Request-URI. If the Request-URI refers to an already existing resource, the enclosed entity SHOULD be considered as a modified version of the one residing on the origin server. If the Request-URI does not point to an existing resource, and that URI is capable of being defined as a new resource by the requesting user agent, the origin server can create the resource with that URI

Vamos, que PUT sirve también para crear recursos.

Estas seguro de que quieres entrar en estandares y demas paja de la informatica? Porque se que en la practica no tienes de donde sacar, pero ya como también te falle leer, va a ser divertido...

#55634 Que porque dices cobrar un sueldo cuando lo minimo que se le puede pedir a uno de carrera es saberse su estandar.

Si ahora te vas a poner finuras porque has hecho el ridículo y vas a sacar de contexto mi tono informal mejor ahorratelo.

Eres tu el que ha empezado con finuras para luego tu mismo no saberte tu estandar.

#55636 Vaya...ahora es caso de uso aislado. Ha durado poco.

#55623desu:

Si un deserializador te pone myNumber a null en el segundo caso está mal. Deberías tener un custom deserializer que te ponga el valor por defecto, 0.

Depende de la lógica de negocio y del contrato de la API.

Si estableces en tu contrato que puedes no recibir un valor en el JSON y eso significa que el valor es null en tu objeto, no recibirlo implica que el deserializer, al no encontrarlo, mapea a null el atributo y a correr. Luego tú en tu servicio ya te apañarás para manejar ese null. Podrías incluso crear un DTO sin ese atributo, pero me parece más peligroso incluso que un null.

En cambio, si la lógica de negocio acepta 0 como valor posible para myNumber no puedes ponerle un 0 por defecto con el deserializer si el valor no viene en el JSON porque te estaría falseando datos.

Lo ideal es no recibir el campo y mapearlo a null. Menos problemas.

En flarum usamos get para actualizar y crear a parte de obtener

#55640 Yo no te he dicho que dupliques nada, yo te he dicho que no tienes ni idea de lo que haces y te lo he explicado.

#55639 No, está mal. No existe caso de uso en el mundo real donde lo que dices tenga sentido. El único motivo para tener un null en cualquier API es tener algo opcional, es decir, que se puede activar/desactivar o estar presente o no. Eso lo puedes representar con 2 campos, tener un enabled/disabled, o tener un objeto map "nullable".

Es tan fácil como tener un {} de metadatos y además es algo que en el futuro se puede expandir y modificar sin romper la API.

Tener el el enabled/disabled o el map de metadatos la diferencia esta que con el enabled/disabled tienes la ultima configuracion guardada, y con el map lo pierdes. Por tanto el user debe de re-crearlo.

#55648 Es exactamente lo que has explicado.

Si tienes:
{
"Name": "John",
"Age": 35
}

Haces un /PUT
{
"Name": "Fpero",
"Age": 35
}

O haces un /PATCH
{
"Name": "Fpero",
}

Aquí te falta la opción que te estoy preguntando que es cuando quiero crear un objecto y editar otro al mismo tiempo.

Así que te vuelvo a preguntar como buena gente de carrera. Entonces uso POST/PUT/PATCH o hago 2 llamadas para seguir el estandar? Porque con tu tutorial, es lo unico que me das a entender