Profesor @mteheran , qué opina de modificar el tipo del método
a
con el fin de poder controlar las posibles IDs inexistentes que lleguen del postman además de enviar como respuesta el objeto modificado ?
Intente otras formas manteniendo la estructura original con al
Task
, pero solo con
pude controlar este caso.
Por último decir que este caso se repite para el método
Profesor @mteheran , qué opina de modificar el tipo del método
a
con el fin de poder controlar las posibles IDs inexistentes que lleguen del postman además de enviar como respuesta el objeto modificado ?
Intente otras formas manteniendo la estructura original con al
Task
, pero solo con
pude controlar este caso.
Por último decir que este caso se repite para el método
Profesor @mteheran , qué opina de modificar el tipo del método
a
con el fin de poder controlar las posibles IDs inexistentes que lleguen del postman además de enviar como respuesta el objeto modificado ?
Intente otras formas manteniendo la estructura original con al
Task
, pero solo con
pude controlar este caso.
Por último decir que este caso se repite para el método
Hay que recordar que el PUT(por no enredar) es un metodo HTTP que no solo sirve para actualizar un recurso/registro/entidad (todos los elementos del mismo) sino que otra de sus acciones es crear un recurso, si el ID del registro no existe PUT lo crea, es lo que hace PUT. Por ende si el objetivo es privar esta funcionalidad (en la mayoria de los casos y en lo personal yo lo hago). Es realizar una validación buscando el registro por id, si existe actualiza, sino, devuelve un 404 NotFound response. Asi que tu pregunta es muy buena y es válida. Te recomiendo que si lo hagas asi validando el Id, claro, no en todos los casos se restringira este comportamiento pero eso ya sera un "depende" del caso de uso que estes trabajando.
Ahora por aparte, el async Task no te recomiendo quitarlo, eso permite que el endpoint maneje la solicitud de manera asincrona(tampoco entrare en detalles) y tu servicio no colapse. Tu puedes manejar los retornos asincronos siempre con Task. Task no solo es una clase tambien tiene implementacion de genericos, puedes usar public async Task<ActionResult<string>> de esta forma tu puedes devolver un Task result, un ActionResult (tus status code normales) o un string. No olvides que todo metodo asincrono que lleve async debe llevar su fiel amigo await. Por lo que puede usar el await tanto en el FirstOrDefault por
await apiContext.Users.FirstOrDefaultAsync() y tambien usarlo en el await apiContext.SaveChangesAsync(). De esta forma tu return no sera un Task, sino lo que vaya dentro del Task (ActionResult o string).
Si lo que dices es totalmente valido y deberia vlidarse y devolver NotFound
Ejemplo:
[HttpPut("{id}")]
public async Task<ActionResult> Put(string id, [FromBody] string value)
{
if((id, out var categoryId)) return BadRequest();
var categoryFound = context.Categories.FirstOrDefault(p=> p.IdCategory == [Guid.Parse](//Guid.Parse)(id));
if (categoryFound!= null)
{
categoryFound.Description_Category = value;
await [context.SaveChangesAsync](//context.SaveChangesAsync)();
return Ok();
}
else
return NotFound();
}
Lo que dice Brandon es cierto de que PUT puede crear el registro pero relamente esto solo se usa cuando la ruta como tal ya existe, como cuando esta llenando un formulario por etapas y se crea el registro del formulario en una tabla y luego las respuestas se van creando poco a poco, dle resto debe devolver NotFound pues si el registro no existe se debe usar POST.
Como dice Brandon te recomiendo conservar el Async ya que al ser asincronos te va permitir crear difernetes hilos por cada request y accion dentro del flujo, cuando hay multiples usuarios conectados mejora mucho el performance y tu servicio va responder siempre. Esto hace parte de las ventajas que C# dotnet tiene sobre otros frameworks
Hay que recordar que el PUT(por no enredar) es un metodo HTTP que no solo sirve para actualizar un recurso/registro/entidad (todos los elementos del mismo) sino que otra de sus acciones es crear un recurso, si el ID del registro no existe PUT lo crea, es lo que hace PUT. Por ende si el objetivo es privar esta funcionalidad (en la mayoria de los casos y en lo personal yo lo hago). Es realizar una validación buscando el registro por id, si existe actualiza, sino, devuelve un 404 NotFound response. Asi que tu pregunta es muy buena y es válida. Te recomiendo que si lo hagas asi validando el Id, claro, no en todos los casos se restringira este comportamiento pero eso ya sera un "depende" del caso de uso que estes trabajando.
Ahora por aparte, el async Task no te recomiendo quitarlo, eso permite que el endpoint maneje la solicitud de manera asincrona(tampoco entrare en detalles) y tu servicio no colapse. Tu puedes manejar los retornos asincronos siempre con Task. Task no solo es una clase tambien tiene implementacion de genericos, puedes usar public async Task<ActionResult<string>> de esta forma tu puedes devolver un Task result, un ActionResult (tus status code normales) o un string. No olvides que todo metodo asincrono que lleve async debe llevar su fiel amigo await. Por lo que puede usar el await tanto en el FirstOrDefault por
await apiContext.Users.FirstOrDefaultAsync() y tambien usarlo en el await apiContext.SaveChangesAsync(). De esta forma tu return no sera un Task, sino lo que vaya dentro del Task (ActionResult o string).
Si lo que dices es totalmente valido y deberia vlidarse y devolver NotFound
Ejemplo:
[HttpPut("{id}")]
public async Task<ActionResult> Put(string id, [FromBody] string value)
{
if((id, out var categoryId)) return BadRequest();
var categoryFound = context.Categories.FirstOrDefault(p=> p.IdCategory == [Guid.Parse](//Guid.Parse)(id));
if (categoryFound!= null)
{
categoryFound.Description_Category = value;
await [context.SaveChangesAsync](//context.SaveChangesAsync)();
return Ok();
}
else
return NotFound();
}
Lo que dice Brandon es cierto de que PUT puede crear el registro pero relamente esto solo se usa cuando la ruta como tal ya existe, como cuando esta llenando un formulario por etapas y se crea el registro del formulario en una tabla y luego las respuestas se van creando poco a poco, dle resto debe devolver NotFound pues si el registro no existe se debe usar POST.
Como dice Brandon te recomiendo conservar el Async ya que al ser asincronos te va permitir crear difernetes hilos por cada request y accion dentro del flujo, cuando hay multiples usuarios conectados mejora mucho el performance y tu servicio va responder siempre. Esto hace parte de las ventajas que C# dotnet tiene sobre otros frameworks
Hay que recordar que el PUT(por no enredar) es un metodo HTTP que no solo sirve para actualizar un recurso/registro/entidad (todos los elementos del mismo) sino que otra de sus acciones es crear un recurso, si el ID del registro no existe PUT lo crea, es lo que hace PUT. Por ende si el objetivo es privar esta funcionalidad (en la mayoria de los casos y en lo personal yo lo hago). Es realizar una validación buscando el registro por id, si existe actualiza, sino, devuelve un 404 NotFound response. Asi que tu pregunta es muy buena y es válida. Te recomiendo que si lo hagas asi validando el Id, claro, no en todos los casos se restringira este comportamiento pero eso ya sera un "depende" del caso de uso que estes trabajando.
Ahora por aparte, el async Task no te recomiendo quitarlo, eso permite que el endpoint maneje la solicitud de manera asincrona(tampoco entrare en detalles) y tu servicio no colapse. Tu puedes manejar los retornos asincronos siempre con Task. Task no solo es una clase tambien tiene implementacion de genericos, puedes usar public async Task<ActionResult<string>> de esta forma tu puedes devolver un Task result, un ActionResult (tus status code normales) o un string. No olvides que todo metodo asincrono que lleve async debe llevar su fiel amigo await. Por lo que puede usar el await tanto en el FirstOrDefault por
await apiContext.Users.FirstOrDefaultAsync() y tambien usarlo en el await apiContext.SaveChangesAsync(). De esta forma tu return no sera un Task, sino lo que vaya dentro del Task (ActionResult o string).
Si lo que dices es totalmente valido y deberia vlidarse y devolver NotFound
Ejemplo:
[HttpPut("{id}")]
public async Task<ActionResult> Put(string id, [FromBody] string value)
{
if((id, out var categoryId)) return BadRequest();
var categoryFound = context.Categories.FirstOrDefault(p=> p.IdCategory == [Guid.Parse](//Guid.Parse)(id));
if (categoryFound!= null)
{
categoryFound.Description_Category = value;
await [context.SaveChangesAsync](//context.SaveChangesAsync)();
return Ok();
}
else
return NotFound();
}
Lo que dice Brandon es cierto de que PUT puede crear el registro pero relamente esto solo se usa cuando la ruta como tal ya existe, como cuando esta llenando un formulario por etapas y se crea el registro del formulario en una tabla y luego las respuestas se van creando poco a poco, dle resto debe devolver NotFound pues si el registro no existe se debe usar POST.
Como dice Brandon te recomiendo conservar el Async ya que al ser asincronos te va permitir crear difernetes hilos por cada request y accion dentro del flujo, cuando hay multiples usuarios conectados mejora mucho el performance y tu servicio va responder siempre. Esto hace parte de las ventajas que C# dotnet tiene sobre otros frameworks