Restituisce un 200 con anche informazioni sugli oggetti non validi quando si passa in una raccolta

Question

Restituisce un 200 con anche informazioni sugli oggetti non validi quando si passa in una raccolta

#1 da (1 voti)

4

Se posso saltare direttamente in esso.

Ho un endpoint web api dove passo in una collezione e funziona in modo sorprendente ma con un avvertimento.

Se un oggetto in quella raccolta contiene dati non validi (dati mancanti mancanti) restituisce una richiesta errata, annullando quindi l'intera collezione - i normali shenanigans ma il lead tecnologico suggerito consente ai buoni di venire attraverso ma restituiscono i dettagli della "cattiva" uno "- beh in termini di richieste http, questo è impossibile, non è possibile inviare contemporaneamente Ok e BadRequest ...

Ho scelto di passare in raccolte per risparmiare sulla risorsa piuttosto che colpire l'api più volte per ogni ordine.

Quello che ho fatto è sottrarre gli ordini "buoni" e passare quelli ad un'altra API, che poi restituisce 200 -

ora sto deliberando su cosa fare con i malformati - manda un messaggio nel 200 con quelli malformati? o inviare per e-mail al cliente gli ordini non andati a buon fine ... un bel problema da avere. Qualche consiglio?

    [HttpPost]
    [Route("orders")]
    [DocMethod(Verb = "POST",
        Description = "Inserts a complete collection of order objects (Inclusive of related objects)",
        EndPoint = "/api/v1/orders",
        Version = "V1")]
    public async Task<IHttpActionResult> Post([FromBody]List<Order> orders)
    {
        var validatedOrders = FilterOrders.Validated(orders);

        if (orders == null && validatedOrders == null)
            return BadRequest("Unusable resources.");

        try
        {
            var identity = User.Identity as ClaimsIdentity;

            var identityModel = IdentityModel.Create(identity);
            if (identityModel == null)
                return StatusCode(HttpStatusCode.Forbidden);

            var response = await _orderService.AddAsync(validatedOrders, identityModel);

            return new DataAPIResult(response.Content.ReadAsStringAsync().Result, response);
        }
        catch (System.Exception ex)
        {
            return InternalServerError();
        }   
    }

Quindi tecnicamente non ho un errore di codice (quindi postare qui) ma più semplicemente un processo di ingegneria. Qualsiasi consiglio molto apprezzato.

c# web-api

posta Tez Wingfield 15.06.2017 - 13:54

fonte

1 risposta

Leggi altre domande sui tag c# web-api

Punto di progettazione per la ricerca di prodotti e il completamento automatico utilizzando la ricerca elastica? Organizzazione di strumenti ad-hoc in una struttura Muti-Repo

score 1 · Accepted Answer

Dipende davvero da come vuoi gestire i tuoi dati. È possibile trattare gli inserimenti sia a livello transazionale che non transazionale e presentano entrambi vantaggi diversi a seconda dell'attività.

Se stai eseguendo un'elaborazione non transazionale e stai bene inserendo solo alcuni degli inserimenti di massa che rispondono con una 200 Ok insieme a messaggi di errore è accettabile e pratica standard.

Una risposta tipica sarebbe.

200 OK
Content-type: application/json
[
    {
        "index": 1,
        "status": "error",
        "messages": [
            "The item can't be added because of the error #22"
        ]
    },
    {
        "index": 2,
        "status": "success",
        "id": "<generated-id>"
    },
    (...)
]

Se desideri trattare le richieste in blocco a livello di transazione, rispondi con una 422 Unprocessable Entity quando ci sono errori di convalida o un errore 500 Internal Server se un problema interno impedisce la registrazione dei dati. In entrambi i casi di errore, è possibile eseguire il rollback di qualsiasi elemento inserito e rispondere con un elenco di messaggi di convalida / errore.

422 Unprocessable Entity
Content-type: application/json
[
    {
        "index": 1,
        "messages": [
            {
                "email": "Must contain an @."
             }
        ]
    },
]

Esistono due soluzioni aggiuntive leggermente più complesse:

Rispondi con 202 Accepted e un ID transazione che può essere interrogato per gli aggiornamenti.
Utilizzo di WebHooks, che implica la creazione di un'API sul client che potrebbe ricevere notifiche dal server.

Alla fine, si tratta di quanto tu sia tollerante al rischio. Se si salvano le transazioni utente per un sistema finanziario, l'intero batch non sarà più sicuro. Tuttavia, se stai inserendo metriche di sistema che perdono alcuni risultati, avrà probabilmente un impatto minimo.