Feda /dev/ - No Javascript allowed | Página 1856

Kaledros #55651 13 May

#55650eXtreM3:
Si te mandan el campo con el valor, lo aplicas al crear el objeto de dominio.
Si no te lo mandan, aplicas lo que corresponda (0 si es 0, null si permites nullables... lo que sea)

Mierda, me he dejado una frase por editar. Ahora.

desu #55652 13 May

#55649 Cuando creas un objeto usa SIEMPRE /POST, cuando lo actualices usa SIEMPRE /PUT o /PATCH.

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

Depende de la estructura del recurso, es un recurso anidado?

1 2 respuestas

Runig666 #55653 13 May 2 Fast 2 Ralli

#55652 Vuelvo a preguntar

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

Depende de la estructura del recurso, es un recurso anidado?

Son dos objectos distintos de la misma clase/tipo, cada uno va por separado.

3 respuestas

privet #55654 13 May

#55652 Y PUNTO

desu #55655 13 May

#55653 Que estructura tienen los recursos.

1 respuesta

eXtreM3 #55656 13 May

#55653Runig666:
crear un objecto y editar otro al mismo tiempo.

Lo que haga tu aplicación por detrás le da igual al naming de la API.

Si el recurso principal, como dices, es CREAR un OBJETO, el endpoint es POST /api/object, no tiene más.

Eso disparará un evento o lo que sea y haces lo que te de la gana con el otro, lo editas por ejemplo.

PD: estoy con @desu en este tema. Hazle caso.

1 respuesta

Runig666 #55657 13 May 2 Fast 2 Ralli

#55655 La misma que te llevo diciendo minuto uno. Tengo X objectos del mismo tipo, que podemos suponer que es un objecto basico de "persona", que tiene el nombre, la edad y la clave primaria de turno. Nada más

En una misma llamada tengo que crear X personas con sus campos y aparte tengo que editar Z que vienen con los mismos campos y aparte la clave, ya que es una edición.

1 respuesta

Fyn4r #55658 13 May Inocente

Si vuelvo a leer objecto me da un ictus

6 1 respuesta

Kaledros #55659 13 May

#55658 ¿Y si lees objeto de da un itus?

Conozco la salida.

3 1 respuesta

Runig666 #55660 13 May 2 Fast 2 Ralli

#55659 Pelea a muerte con objectos
#55656

PD: estoy con @desu en este tema. Hazle caso.

Estupendo...como le llamo? POST o PUT?

Que yo no estoy diciendo que este bien POST ni estoy diciendo que este bien PUT...estoy preguntado por teóricamente que tendría que poner.

1 respuesta

eXtreM3 #55661 13 May

#55660 POST.

Que tengas el código acopladísimo a muerte no es responsabilidad de la API.

1 respuesta

desu #55662 13 May

#55657 La unica dificultad que puedes tener es tener recursos anidados:

#55653 Que estructura tienen los recursos.

Si por ejemplo tienes un recurso Configuration dentro de tu Person, y que tengas endpoints especificos para /POST /PUT /PATCH /DELETE, que se encarguen de hacer attach/detach y modificar estas configuraciones para los usuarios.

Yo te recomiendo que no tengas esto si no necesitas una configuracion dinamica, es un caso de nuevo muy aislado. Lo mejor es que si quieres cambiar la configuracion, esta sea simplemente un campo dentro de Person y no otro recurso (en su propia tabla en db probablemente que necesitaras pasar foreign keys).

{
 "Name" : "Fpero"
 "Age": 123
 "Configuration": {
    (...)
  }
}

Si tienes una lista de Person y quieres crear y modificar Person existen tres casos de uso.

La lista de Person, en si, es un recurso y tienes un endpoint /POST listPerson o /PUT listPerson, que le pasas TODOS los Person de tu programa. En tu caso el ID y el recurso seria el ID de la lista de Person, no las person en si.
Person es un recurso, /POST person y /PUT person, en este caso si deberias mandar multiples peticiones HTTP para cada caso, multiples POST para crear, y multiples PUT/PATCH.
Tienes un endpoint para operaciones en batch, asyncrono, que requiere un modelado especial y es un caso de uso distinto, esto solo se deberia hacer si haces decenas de miles de peticiones http por segundo.

Yo recomiendo hacer lo segundo siempre, hasta que el numero de peticiones sea un cuello de botella en el servidor, entonces introducir operaciones en batch en tu API mediante 3. Las cuales son una API async tipica. En mi experiencia, hasta decenas de miles de peticiones por segundo puedes hacer 2 sin problema en un stack normal. A partir de esas 10k req/s 24h al dia ya es mucha carga que compensa optimizar. Eso miralo en las metricas.

Lecherito #55663 13 May A toda leche

Pues hoy estaba pensando en usar las operaciones como metodos RPC por HTTP

1 respuesta

Runig666 #55664 13 May 2 Fast 2 Ralli

#55661 Vale gracias genial, una respuesta.

1 respuesta

desu #55665 13 May

#55663 Mejor aún, a mí me gusta más.

Pero si algo es un CRUD prefiero usar HTTP como esta pensado, y solo hace RPC sobre HTTP para casos de uso complejos de mi dominio. Al final estas ultimas suelen ser operaciones async todas...

desu #55666 13 May

#55664 Esa respuesta está mal porque tu código está mal, la mía está bien.

Arregla tu código de mierda y déjate de cuentos chinos.

Tanta tontería para cuatro formularios de mierda.

1 respuesta

Runig666 #55667 13 May 2 Fast 2 Ralli

#55666

Esa respuesta está mal porque tu código está mal, la mía está bien.

Es decir, tu respuesta que no me da la solución al problema que tengo esta bien. Porque tu respuesta despues de darme largas 10 mensajes han sido las que yo esperaba...dividelo en 2 llamadas y a tomar por saco.

1 respuesta

desu #55668 13 May

#55667 Te he dicho que mandes múltiples peticiones si es un recurso.

¿Cuantas peticiones por segundo tienes?

1 respuesta

Runig666 #55669 13 May 2 Fast 2 Ralli

#55668 Pero vas a volver al bucle para ofrecerme de nuevo lo mismo?

Person es un recurso, /POST person y /PUT person, en este caso si deberias mandar multiples peticiones HTTP para cada caso, multiples POST para crear, y multiples PUT/PATCH.

Tienes un endpoint para operaciones en batch, asyncrono, que requiere un modelado especial y es un caso de uso distinto, esto solo se deberia hacer si haces decenas de miles de peticiones http por segundo.

Si ya lo has dicho bien antes. Tu solución, a no ser que sea asyncrono, pasa por dividirlo en 2 llamadas.

1 respuesta

desu #55670 13 May

#55669 ¿Cuantas peticiones por segundo tienes?

PS: Cuando toda la clase de fperos lo ha entendido menos tu, el problema no es el sensei.

1 respuesta

Runig666 #55671 13 May 2 Fast 2 Ralli

#55670

PS: Cuando toda la clase de fperos lo ha entendido menos tu, el problema no es el sensei.

Si, y yo te he entendido desde el primer momento. Tu solución pasa por separarlo en 2 llamadas y tener un método aparte para hacerlo todo junto si son muchas llamadas por segundo.

Dicho metodo aparte sigo sin saber la respuesta de si lo harías POST o PUT...

1 respuesta

desu #55672 13 May

#55671Runig666:
Si, y yo te he entendido desde el primer momento.

¿Y que problema tienes? ¿Cuantas peticiones por segundo tienes?

#55671Runig666:
Tu solución

No es mi solución, es la única manera correcta, no hay otra.

#55671Runig666:
Dicho metodo aparte sigo sin saber la respuesta de si lo harías POST o PUT...

Diseñar una API asíncrona ahora mismo escapa a tus conocimientos.

1 respuesta

Runig666 #55673 13 May 2 Fast 2 Ralli

#55672

Diseñar una API asíncrona ahora mismo escapa a tus conocimientos.

Pero no a los tuyos, o eso dices. Es POST o PUT?

1 respuesta

desu #55674 13 May

#55673 De nuevo, depende, te lo he explicado antes.

El mayor problema en el sistema distribuido es evitar hacer trigger de muchas operaciones equivalentes, si por ejemplo quieres hacer un delete de [a,b,c] y manda el cliente 3 órdenes (post o put) con delete [a,b,c] el sistema, idealmente, debería solo ejecutar 1 vez esa operación.

Una API asíncrona tiene 2 endpoints, uno para crear y gestionar el estado del job, y otro para obtener el resultado del job.

La manera creo más simple y fácil es hacer un /POST con delete [a,b,c] que devuelva un ID para ese job, y luego mediante un PUT pasar este job a RUNNING y que se ejecute, donde en otro endpoint puedes comprobar el estado y obtener los resultados.

Una modificación que añade complejidad a cambio de evitar duplicados, para evitar múltiples delete de [a,b,c] si es algo que puede saturar tu sistema, es que mediante una transacción al hacer el POST comprobar que el "delete [a,b,c]" es único (no está created o running, pero puede estar completed) en db mediante un hash, y luego de nuevo proceder ejecutando un PUT para hacer run. Pero para ello usas 2 peticiones HTTP y necesitas definir el hash que haga las operaciones únicas.

Ahora en tu caso de uso por ejemplo, imagina que quieres hacer un /PUT de múltiples recursos en batch, que pasa si el usuario me manda múltiples de estas operaciones en batch? Se sobre-escribe el resultado? En que orden se deberían ejecutar? El motivo por el que nunca debes empezar por el batch es porque añade dificultades y problemas de sistemas distribuidos a tu problema, y como nos ha quedado claros a todos, eres un fpero que actualiza 4 formularios de mierda.

Depende del caso de uso concreto, existirán problemas y restricciones de dominio, que al ser un sistema distribuido en lugar de una única transacción deberás gestionar. En el caso de los updates, pues el orden es un claro ejemplo. En el caso de los create, el no crear multiples recursos iguales, o correr hot paths en paralelo que puedan crear inconsistencias en el sistema.

A mis conocimientos no se escapa nada fpero, soy top 0,001% del mundo disenando APIs y HTTP en general, subnormal.

1 respuesta

Wei-Yu #55675 13 May

no me he leído nada pero cual es el resumen de que si tienes un campo nullable tener un put idempotente con el que poder setear a null ese campo está mal?

1 respuesta

Runig666 #55676 13 May 2 Fast 2 Ralli

#55674

El motivo por el que nunca debes empezar por el batch es porque añade dificultades y problemas de sistemas distribuidos a tu problema, y como nos ha quedado claros a todos, eres un fpero que actualiza 4 formularios de mierda.

A mi lo que me ha quedado claro es que me ha llevado media tarde que des algo parecido a una respueta.

A mis conocimientos no se escapa nada fpero, soy top 0,001% del mundo disenando APIs y HTTP en general, subnormal.

No seas modesto, top supremo sin porcentaje.

2 respuestas

desu #55677 13 May

#55676 Juego contigo, desnudo las pocas capas que forman tu intelecto y las acomodo como quiero para burlarme de ti, hacer escarmiento público contigo y llevarte al fango.

Cuantas peticiones por segundo dices que tiene tu formulario?

AHAHAHAHAHAHAHA

eondev #55678 13 May Rawe Ceek

#55675 desu se tira un triple y a partir de ahí va saliendo como puede del apuro

3 1 respuesta

desu #55679 13 May

#55676Runig666:
No seas modesto, top supremo sin porcentaje.

Wei-Yu #55680 13 May

#55678 yo aún no acabé de hacerme la raza en el stellaris

estoy haciéndome unos hongos que parasitaron unos mamiferos con perks de fuerza en plan simbiosis mente colmena y primates mazaos a ver cómo hago que todo gire en torno a eso

aún me rayo y me cojo a los árboles agrocomunistas que vienen ya hechos

2 respuestas

Feda /dev/ - No Javascript allowed

Normas basicas de convivencia:

Memes Feda/dev

Usuarios habituales