ASP.NET API principales controladores suelen regresar tipos explícitos (y lo hacen por defecto, si se crea un nuevo proyecto), algo así como:

[Route("api/[controller]")]
public class ThingsController : Controller
{
    //GET api/things
    [HttpGet]
    public async Task<IEnumerable<Thing>> GetAsync()
    {
        //...
    }

    //GET api/things/5
    [HttpGet("{id}")]
    public async Task<Thing> GetAsync(int id)
    {
        Thing thingFromDB = await GetThingFromDBAsync();
        if(thingFromDB == null)
            return null; //This returns HTTP 204

        //Process thingFromDB, blah blah blah
        return thing;
    }

    //POST api/things
    [HttpPost]
    public void Post([FromBody]Thing thing)
    {
        //..
    }

    //... and so on...
}

El problema es que return null; – devuelve un HTTP 204: el éxito, no el contenido.

Esto es considerado por una gran cantidad de cliente de Javascript del lado de los componentes como el éxito, por lo que hay un código como:

const response = await fetch('.../api/things/5', {method: 'GET' ...});
if(response.ok)
    return await response.json(); //Error, no content!

Una búsqueda en línea (tales como esta pregunta y esta respuesta) puntos útiles return NotFound(); los métodos de extensión para el programador, pero todos estos retorno IActionResult, que no es compatible con mi Task<Thing> tipo de retorno. Que patrón de diseño se parece a esto:

//GET api/things/5
[HttpGet("{id}")]
public async Task<IActionResult> GetAsync(int id)
{
    var thingFromDB = await GetThingFromDBAsync();
    if (thingFromDB == null)
        return NotFound();

    //Process thingFromDB, blah blah blah
    return Ok(thing);
}

Que funciona, pero es el tipo de retorno de GetAsync debe ser cambiado a Task<IActionResult> – la escritura explícita se pierde, y todos los tipos de devolución en el controlador tiene que cambiar (es decir, no uso explícito de escribir en todos) o habrá una mezcla donde algunas acciones lidiar con tipos explícitos, mientras que otros. Además de la unidad de pruebas que actualmente se necesita para hacer suposiciones acerca de la seriación y explícitamente deserialise el contenido de la IActionResult donde antes había un tipo concreto.

Hay un montón de maneras de evitar esto, pero parece ser un confuso revoltijo que fácilmente podría ser diseñado, de modo que la pregunta real es: ¿cuál es la forma correcta de la intención por la ASP.NET diseñadores?

Parece que las opciones posibles son:

  1. Tiene un extraño (desordenado a la prueba) de la mezcla de tipos explícitos y IActionResult dependiendo del tipo esperado.
  2. Olvidarse de tipos explícitos, no están soportados por el Núcleo MVC, siempre uso IActionResult (en cuyo caso, ¿por qué están presentes en todos?)
  3. Escribir una implementación de HttpResponseException y utilizarlo como ArgumentOutOfRangeException (ver esta respuesta para una aplicación). Sin embargo, que no requieren el uso de excepciones para el flujo de un programa, que generalmente es una mala idea y también en desuso por la MVC equipo central.
  4. Escribir una implementación de HttpNoContentOutputFormatter que devuelve 404 para peticiones GET.
  5. Algo que me falta en cómo Core MVC se supone que funciona?
  6. O hay una razón por la que 204 es correcta y 404 mal por un error en la petición GET?

Estos implican compromisos y refactorización que perder algo o agregar lo que parece ser una complejidad innecesaria en desacuerdo con el diseño de la MVC Núcleo. Que el compromiso es la correcta y por qué?

  • Posibles duplicados de Cómo devolver HTTP 500 de ASP.NET Núcleo RC2 Web Api?
  • hola, ¿la has leído la pregunta? Estoy especialmente conscientes de StatusCode(500) y sólo funciona con las acciones que volver IActionResult, que luego de entrar en algunos detalles.
  • Es el mismo principio….y sí, he leído la pregunta
  • no, es concretamente ¿no. Que sólo funciona con IActionResult. Estoy preguntando sobre acciones explícitas de tipos. Voy a indagar sobre el uso de IActionResult en la primera viñeta, pero no estoy preguntando cómo llamar a StatusCode(404) – ya lo sé, y citan en la pregunta.
  • ¿De verdad leer el Q&A…¿la has leído todas las alternativas que se proponen?…Me refiero a ¿incluso probar o simplemente quieres que alguien con una respuesta completa…deja de quejarte, acabo de publicar un posible duplicado, no me downvote o votar para cerrar tu pregunta….jesús
  • Por su escenario, la solución podría ser algo como return new HttpResponseMessage(HttpStatusCode.NotFound); …también de acuerdo a este: docs.microsoft.com/en-us/aspnet/core/mvc/models/formatting For non-trivial actions with multiple return types or options (for example, different HTTP status codes based on the result of operations performed), prefer IActionResult as the return type.
  • usted votó a favor de cerrar mi pregunta como una víctima de una pregunta que me había encontrado, leído y vivido antes hice esta pregunta y que me dirigí a la pregunta, no la respuesta que estaba buscando. Obviamente me fui a la defensiva – quiero una respuesta a mi pregunta, no se apuntó en un círculo. Su comentario final es realmente útil y comienza a abordar lo que en realidad estoy preguntando sobre – usted debe carne a una respuesta completa.
  • Bueno, voy a recoger un poco más de info, solo para estar seguro al 100%.
  • Ok, lo tengo más info sobre el tema…con el fin de lograr algo así(todavía creo que el mejor enfoque debe ser el uso de IActionResult), usted puede seguir este ejemplo public Item Get(int id) { var item = _repo.FindById(id); if (item == null) throw new HttpResponseException(HttpStatusCode.NotFound); return item; } donde usted puede devolver un HttpResponseException si thing es null
  • eso tiene mucho más sentido – lanzar una excepción para un estado de error (aunque todavía tengo la sospecha de que el servidor de excepciones debe ser 5xx estados, pero que podría ser mi interior codificación pedante). También tiene el potencial de viaje de cualquier registro de la excepción innecesariamente. Voy a darle algunas pruebas. Poner esto en una respuesta – se ha vuelto a lo grande para los comentarios.
  • hecho!!…únete a mí en linkedin (está en mi perfil)
  • También puedo agregar contra IActionResult: decisiones de tipo de retorno implícita de las fuerzas de su unidad de pruebas a ser incómodo en conseguir objetos subyacentes.
  • sí, véase el punto 1. por encima de.

InformationsquelleAutor Keith | 2017-01-04

4 Comentarios

  1. 44

    Este es dirigida en ASP.NET Core 2.1 con ActionResult<T>:

    public ActionResult<Thing> Get(int id) {
        Thing thing = GetThingFromDB();
    
        if (thing == null)
            return NotFound();
    
        return thing;
    }

    O incluso:

    public ActionResult<Thing> Get(int id) =>
        GetThingFromDB() ?? NotFound();

    Voy a actualizar esta respuesta con más detalle una vez que he puesto en práctica.

    Respuesta Original

    En ASP.NET Web API 5 hubo un HttpResponseException (como se ha señalado por Hackerman) pero ha sido eliminado de Core y no hay middleware para manejarlo.

    Creo que este cambio es debido .NET Core – donde ASP.NET intenta hacer todo lo que fuera de la caja, ASP.NET Core solo hace lo que le específicamente a (que es una gran parte de por qué es mucho más rápido y portátil).

    No puedo encontrar una biblioteca existente que hace esto, así que lo he escrito yo mismo. En primer lugar, necesitamos una excepción personalizada para comprobar:

    public class StatusCodeException : Exception
    {
        public StatusCodeException(HttpStatusCode statusCode)
        {
            StatusCode = statusCode;
        }
    
        public HttpStatusCode StatusCode { get; set; }
    }

    Entonces tenemos una RequestDelegate controlador que comprueba que la nueva excepción y la convierte en la respuesta HTTP de código de estado:

    public class StatusCodeExceptionHandler
    {
        private readonly RequestDelegate request;
    
        public StatusCodeExceptionHandler(RequestDelegate pipeline)
        {
            this.request = pipeline;
        }
    
        public Task Invoke(HttpContext context) => this.InvokeAsync(context); //Stops VS from nagging about async method without ...Async suffix.
    
        async Task InvokeAsync(HttpContext context)
        {
            try
            {
                await this.request(context);
            }
            catch (StatusCodeException exception)
            {
                context.Response.StatusCode = (int)exception.StatusCode;
                context.Response.Headers.Clear();
            }
        }
    }

    Luego de registrar este middleware en nuestro Startup.Configure:

    public class Startup
    {
        ...
    
        public void Configure(IApplicationBuilder app)
        {
            ...
            app.UseMiddleware<StatusCodeExceptionHandler>();

    Finalmente acciones puede lanzar el código de estado HTTP excepción, mientras que todavía devolver un tipo explícito que puede ser fácilmente unidad de prueba sin necesidad de conversión de IActionResult:

    public Thing Get(int id) {
        Thing thing = GetThingFromDB();
    
        if (thing == null)
            throw new StatusCodeException(HttpStatusCode.NotFound);
    
        return thing;
    }

    Esto mantiene los tipos explícitos para la devolución de los valores y permite una fácil distinción entre los exitosos resultados vacíos (return null;) y un error porque algo no puede ser encontrado (creo que es como tirar una ArgumentOutOfRangeException).

    Mientras que esta es una solución para el problema que aún no tiene respuesta a mi pregunta – los diseñadores de la Web de la API de construir el soporte para tipos explícitos con la expectativa de que vayan a utilizarse, agregado de manejo específico para return null; de modo que se produciría una 204 en lugar de 200, y luego no agregar ninguna manera de lidiar con el error 404? Parece como un montón de trabajo para agregar algo tan básico.

    • Yo creo que si la ruta de recurso es válido, pero no devuelve nada, la respuesta correcta debe ser 204(Sin Contenido)….si la ruta no existe, debe devolver una respuesta 404(no encontrado)…tiene sentido, ¿verdad?
    • Sospecho que bien podría ser una opción, pero un montón de lado de cliente de la Api de generalizar (1xx en ella… 2xx ok, 3xx ir aquí, 4xx se equivocó, 5xx lo hicimos mal) – 2xx implica que todo está bien, cuando en realidad el usuario solicita un recurso que no existe (como en el ejemplo de mi pregunta, la Fetch API considera 204 como ACEPTAR para continuar). Supongo 204 podría significar la derecha ruta de acceso a recursos, mal IDENTIFICADOR de recurso, pero que no ha sido de mi entendimiento. Cualquier cita en la que, como el patrón deseado?
    • Echa un vistazo a este artículo racksburg.com/choosing-an-http-status-code …creo que el diagrama de flujo para los códigos de estado 2xx/3xx explica muy bien…usted puede mirar a los otros también :)\
    • Que todavía señala a 404 ser correcto en este contexto.
    • Nope…cuando dicen Does the resource even exist, que son el significado http recurso, no el contenido de esa respuesta…por ejemplo la solicitud a la api extremo es bueno y yo era capaz de llegar a ella, sí, entonces usted tiene una 2XX respuesta…cuando hablamos de un restful api, hablamos de http de los recursos, como una forma más natural htpp manera..así que si un usuario fue capaz de golpear a su api extremo de entonces, una respuesta http 404 no tiene sentido..pero si la respuesta del servidor es un vacío, entonces la respuesta adecuada debería ser 204, sí, usted golpea el extremo derecho, pero tengo una respuesta vacía ahora.
    • Realmente no estoy seguro de en que parece que tratando de transmitir información acerca de la API en la API. Si estamos haciendo que no deberíamos implementar también 405 (en lugar de 404) para la válida controladores sin la acción solicitada y así sucesivamente? En el DESCANSO la cosa que se devuelve es el recurso, no la propia API. Yo creo que por eso la convención para los nombres en plural (en lugar de singular como lo sería en una DB) – api/things/5 es el recurso que espera a ser una sola cosa.
    • Recursos Http, http válida recursos….recuerda que el DESCANSO no se preocupa por la lógica detrás de esto….Se me olvida a veces que no tienen una junta en la que se puede escribir o dibujar cosas xD…
    • sí, ese es el tipo de por qué creo que api/missing y api/valid/missing debe devolver un mensaje de error 404, no 404 para la ex y 204 para el segundo.
    • Si ha definido una ruta válida en su aplicación para api/valid/{$id} por ejemplo, y tratar de golpear a ese extremo con api/valid/21 tiene un 2xx respuesta; no importa si ese id con el valor de 21 existe o no en la base de datos o si se produce un contenido de resultado o no, los recursos existentes(http recurso extremo de api)…si 21 produce un resultado, entonces usted tiene un 200 con, por ejemplo, un resultado en json…y si no devuelve un resultado vacío, a continuación, un 204…Es un poco difícil de entender, me tomó un tiempo cuando empiezo con esto también 🙂
    • pero no es que la incrustación de información sobre el RESTO de servicios en los códigos – si la ruta es válida con una falta de identidad, o el controlador de válida sin una implementación para el verbo HTTP, o la ruta a la acción no válida en sí misma, o incluso el tipo de mal (api/valid/abc cuando el ID es un int devolverá un mensaje de error 404) – no es que tratando de exponer los detalles de la implementación del servicio?
    • Vamos a hacer lo contrario…me muestran en cuyo caso usted debe devolver un 204 código de estado?
    • POST JSON cosa api/things/5 hits public void Post o public async Task PostAsync y se aplica con éxito los cambios con nada para el informe, pero el éxito. El MVC diseñadores han añadido HttpNoContentOutputFormatter a la fuerza que volver 204 en lugar de 200.
    • Y si 5 no es válido o no existe…o el thing con el id está marcado con un suave eliminar en la tabla primaria….luego, basándose en lo que sus comentarios anteriores en que caso se debe devuelve un 404 código de estado?
    • Que podría variar por la API – POST puede llevar a cabo upsert estilo de las acciones, pero si quería estricto actualizaciones de este POST y PONER adiciones entonces sí, la falta de una IDENTIFICACIÓN sería 404, mientras que una actualización correcta sería 204.

  2. 14

    Usted puede utilizar realmente IActionResult o Task<IActionResult> en lugar de Thing o Task<Thing> o incluso Task<IEnumerable<Thing>>. Si usted tiene una API que devuelve JSON entonces usted puede simplemente hacer lo siguiente:

    [Route("api/[controller]")]
    public class ThingsController : Controller
    {
        //GET api/things
        [HttpGet]
        public async Task<IActionResult> GetAsync()
        {
        }
    
        //GET api/things/5
        [HttpGet("{id}")]
        public async Task<IActionResult> GetAsync(int id)
        {
            var thingFromDB = await GetThingFromDBAsync();
            if (thingFromDB == null)
                return NotFound();
    
            //Process thingFromDB, blah blah blah
            return Ok(thing); //This will be JSON by default
        }
    
        //POST api/things
        [HttpPost]
        public void Post([FromBody] Thing thing)
        {
        }
    }

    Actualización

    Parece como si la preocupación es que se explícita en el retorno de una API es de alguna manera útil, aunque es posible ser explícita es, de hecho, no es muy útil. Si usted está escribiendo la unidad de pruebas de que el ejercicio de la petición /respuesta de tubería normalmente se va a verificar el retorno primas (que sería lo más probable es JSON, es decir; una cadena en C#). Usted podría simplemente tomar la cadena devuelta y volver a convertir el inflexible equivalente para las comparaciones utilizando Assert.

    Esta parece ser la única desventaja con el uso de IActionResult o Task<IActionResult>. Si usted realmente, realmente quiero ser explícito y todavía quieren que establece el código de estado hay varias maneras de hacer esto – pero no está bien visto, ya que el framework ya tiene un mecanismo incorporado para esto, es decir; el uso de la IActionResult método de devolución de los encapsuladores en los Controller clase. Podría escribir algunos personalizado middleware para manejar esto, sin embargo, le gustaría, sin embargo.

    Por último, me gustaría señalar que si una llamada a la API devuelve null según W3 un código de estado de 204 es realmente correcto. ¿Por qué en la tierra para que quieres un 404?

    204

    El servidor ha cumplido con la petición, pero no tiene que devolver un
    entidad-cuerpo, y puede ser que desee para volver actualizado de metainformación. El
    la respuesta PUEDE incluir nuevos o actualizados de metainformación en la forma de
    entidad-cabeceras, que si está presente DEBE estar relacionado con el
    solicitado variante.

    Si el cliente es un agente de usuario, NO DEBE cambiar su vista de documento
    que causó la solicitud para ser enviado. Esta respuesta es
    pensado principalmente para permitir la entrada de acciones a llevar a cabo sin
    causando un cambio en el agente de usuario del documento activo punto de vista, aunque
    cualquier nuevo o actualizado de metainformación DEBE ser aplicado al documento
    actualmente en el agente de usuario de la vista activa.

    El 204 respuesta NO DEBE incluir el cuerpo del mensaje, y así es siempre
    terminada la primera línea vacía después de los campos de encabezado.

    Creo que la primera frase del segundo párrafo dice, «Si el cliente es un agente de usuario, NO DEBE cambiar su vista de documento que causó la solicitud para ser enviado». Este es el caso de una API. En comparación con un 404:

    El servidor no ha encontrado nada que coincida con el URI de la Solicitud. No
    indicación de si la condición es temporal o
    permanente. El 410 (Ido) código de estado DEBE ser utilizado si el server
    conoce, a través de algunos internos mecanismo configurable, que un viejo
    recurso está permanentemente disponible y no tiene una dirección de reenvío.
    Este código de estado es comúnmente utilizado cuando el servidor no desea
    revelan exactamente la razón por la que la solicitud haya sido denegada, o cuando no hay otra
    la respuesta es aplicable.

    La principal diferencia es que uno es más aplicable para una API y el otro para la vista del documento, es decir; la página que se muestra.

    • Hola David, saludos. Me doy cuenta de que puedo cambiar para volver IActionResultpero si esta es la respuesta ¿por qué el ASP.NET Núcleo de la API de soporte de Controlador de las conversiones de tipo implícito en todo si IActionResult, es realmente necesario?
    • Si usted realmente piensa de él, una API que pretende devolver un Thing que realmente devuelve null es en realidad el no-cuerpo 204. Si quieres devolver algo que es más flexible en el marco compatible con enfoque es el uso de IActionResult. No debería ser el marco de la responsabilidad de asumir cualquier cosa, especialmente 404. Pero, de nuevo, usted tiene la capacidad para hacerlo de esta manera. Como alternativa, también puede personalizar el middleware para establecer el Response.StatusCode si quieres en lugar de ello, pero ¿por qué pasar por la molestia?
    • Ya hay HttpNoContentOutputFormatter middleware asegurar que null consigue un 204 en lugar de 200. No quiero el marco suponer nada – en realidad no quiero reemplazar su comportamiento por defecto, sin comprender exactamente por qué lo hicieron de esa manera. Parece que public void Post totalmente debe volver a 204 en caso de éxito, pero public Anything Get(id) no debería devolver un código de éxito de un error en la acción. Siento que algo me falta, acerca de la intención de las mejores prácticas.
    • Este utiliza Json para devolver el IActionResult – que funciona, pero de códigos de disco duro serialiser. Realmente quieres ser capaz de cambiar el serializador (digo XML) a nivel mundial sin necesidad de cambiar cada método. La mejor práctica parece ser la utilización de return Ok(thing);
    • Saludos 🙂 Esta parece ser la propuesta de la práctica (github.com/aspnet/Mvc/issues/4311#issuecomment-271052290), pero si es así, mi punto es que desde el primer comentario sigue en pie. He +1, pero alguien ha silencio votada abajo (lo cual es útil).
    • mi respuesta es la respuesta para esta pregunta. El primer comentario se refiere a que técnicamente es una cuestión separada de esta. Son más curioso acerca de las pruebas ahora o qué?
    • Saludos David, pero no lo es – que comentario es una cita directa de mi pregunta. También de mi pregunta yo no estoy en busca de volver NotFound(); como una respuesta – estos solo funcionan con IActionResult … que parece hacer explícitos los tipos de devolución sin sentido Que es lo que realmente estoy haciendo, no «¿Cómo puedo usar NotFound()«, sino «¿debo volver 404 con escritura explícita» – su respuesta parece ser «no utilizar explícita escribiendo», pero si es así, le faltan las críticas de detalle como para ¿por qué explícita escribiendo es el valor por defecto (o incluso se admite en absoluto)
    • Saludos para la actualización 🙂 por Eso pensé que agregó HttpNoContentOutputFormatter – 204 es correcta cuando el cambio no debe ser visto en el cliente del punto de vista, es perfecto para cualquier cosa que devuelve void o Task (como la mayoría de los POST de acciones). Sin embargo, para api/things/5 – hay un cambio evidente para el cliente y que debería ver algún tipo de mensaje no se encontró.
    • Hemos estado hablando de CONSEGUIR api/things/5 devuelve un 404 si no se encuentra. Qué POST api/things/5 – si se realiza correctamente debe devolver un 204 (que es lo que public void Post o public async Task PostAsync hace), pero si no se ha podido actualizar porque no es cosa de 5, entonces ¿no debería devolver un 404 demasiado? Seguramente no debería devolver un éxito cuando ha fracasado?
    • Esta debe ser la respuesta correcta…y acerca de los códigos de estado, existen diferentes implementaciones(algunos de los usos que uno de los códigos, algunos de los usos que otro), basándose en lo que se quiere lograr y cómo…si desea utilizar un 404 en algunos casos, y siempre que su api está bien documentado, no debería ser un problema.
    • Esto no debería ser la respuesta correcta. Si desea /get/{id} y no hay ningún elemento de ese id en el servidor, un 404 – no encontrado es la respuesta correcta a la que. Y en cuanto a ser explícito – la información de tipo de método se utiliza realmente en herramientas como la arrogancia que dependen de los controladores de declaración para ser capaz de generar el correcto arrogancia de archivo. Así IActionResult se encuentra una gran cantidad de información en este caso.
    • Lo bueno es que este no fue aceptado como respuesta correcta. Gracias por comentar. 🙂

  3. 3

    Con el fin de lograr algo así(aún así, creo que el mejor enfoque debe ser el uso de IActionResult), usted puede seguir, donde se puede throw un HttpResponseException si su Thing es null:

    //GET api/things/5
    [HttpGet("{id}")]
    public async Task<Thing> GetAsync(int id)
    {
        Thing thingFromDB = await GetThingFromDBAsync();
        if(thingFromDB == null){
            throw new HttpResponseException(HttpStatusCode.NotFound); //This returns HTTP 404
        }
        //Process thingFromDB, blah blah blah
        return thing;
    }
    • Saludos (+1) – creo que este es un paso en la dirección correcta, pero (en pruebas) HttpResponseException y el middleware para controlar que no parecen estar en .NET Core 1.1. La siguiente pregunta es: si yo hago mi propio middleware o es que hay un existente (idealmente MS) paquete que ya lo hace?
    • Parece que esta fue la forma de hacer esto en ASP.NET Web de la API de 5, pero se ha caído en el Núcleo, lo cual tiene sentido dado el Núcleo del enfoque manual. En la mayoría de los casos donde el Núcleo se ha reducido un defecto ASP comportamiento hay un nuevo opcional middleware que se pueden agregar en Startup.Configure, pero no parece ser de aquí. En lugar de que no parece ser demasiado difícil escribir desde cero.
    • Ok, he desarrollado una respuesta basada en esto que hace el trabajo, pero aún no responde a la pregunta original: stackoverflow.com/a/41484262/905
    • Echa un vistazo a este: github.com/aspnet/Mvc/issues/4311
  4. 0

    Lo que estás haciendo con el retorno de «Tipos Explícitos» desde el controlador no va a cooperar con el requisito explícitamente a lidiar con su propia código de respuesta. La solución más sencilla es ir con IActionResult (como otros han sugerido); sin Embargo, también se puede controlar de forma explícita su tipo de retorno utilizando el [Produces] filtro.

    Utilizando IActionResult.

    La manera de conseguir el control sobre el estado de resultados, se necesita devolver un IActionResult que es donde usted puede tomar ventaja de la StatusCodeResult tipo. Sin embargo, ahora tenemos el problema de querer forzar un partiular formato…

    Las cosas a continuación está tomado de los Documentos de Microsoft: El formato de los Datos de Respuesta -Forzando un Formato en Particular

    Obligando a un Formato Particular

    Si quieres restringir el formato de respuesta para un determinado
    la acción puede, se puede aplicar el [Produces] filtro. El
    [Produces] filtro especifica el formato de respuesta para un determinado
    la acción (o controlador). Como la mayoría de los Filtros, este puede ser aplicado en
    la acción, de controlador, o de ámbito global.

    Poniendo todo junto

    He aquí un ejemplo de control sobre la StatusCodeResult además del control sobre el «retorno explícito de tipo».

    //GET: api/authors/search?namelike=foo
    [Produces("application/json")]
    [HttpGet("Search")]
    public IActionResult Search(string namelike)
    {
        var result = _authorRepository.GetByNameSubstring(namelike);
        if (!result.Any())
        {
            return NotFound(namelike);
        }
        return Ok(result);
    }

    Yo no soy un gran seguidor de este patrón de diseño, pero he puesto esas preocupaciones en algunas de las respuestas a las preguntas de otras personas. Usted debe notar que el [Produces] filtro requiere que usted mapa de la Formateador /Serializador /Tipo Explícito. Usted puede tomar un vistazo a esta respuesta para obtener más ideas o esta otra para la implementación de un control más granular sobre su ASP.NET Core API Web.

    • Saludos @Svek, que es muy interesante, pero un poco tangencial. No estoy realmente interesado (en esta pregunta, de todos modos) con el formato posible con IActionResult, sino más bien la necesidad de que en el primer lugar.

Dejar respuesta

Please enter your comment!
Please enter your name here