Προγραμματισμός

Τα δύο σεντ μου σχετικά με τη χρήση της διεπαφής IHttpActionResult στο WebAPI

Το WebAPI της Microsoft υπήρξε εδώ και αρκετό καιρό το πλαίσιο επιλογής για τη δημιουργία υπηρεσιών RESTful που μπορούν να λειτουργούν μέσω HTTP. Η διεπαφή IHttpActionResult εισήχθη με το WebAPI έκδοση 2 και παρέχει έναν διαφορετικό τρόπο αποστολής απαντήσεων από τις μεθόδους του ελεγκτή WebAPI και αξιοποιεί το async και περιμένει από προεπιλογή.

Ουσιαστικά, το IHttpActionResult είναι ένα εργοστάσιο για το HttpResponsemessage. Η διεπαφή IHttpActionResult περιλαμβάνεται στο χώρο ονομάτων System.Web.Http και δημιουργεί μια παρουσία του HttpResponseMessage ασύγχρονα. Το IHttpActionResult περιλαμβάνει μια συλλογή από προσαρμοσμένες ενσωματωμένες απαντήσεις που περιλαμβάνουν: Ok, BadRequest, Exception, Conflict, Redirect, NotFound και Unauthorized.

Η διεπαφή IHttpActionResult περιέχει μόνο μία μέθοδο. Δείτε πώς φαίνεται αυτή η διεπαφή:

namespace System.Web.Http

{

δημόσια διεπαφή IHttpActionResult

    {

Task ExecuteAsync (CancellationToken CancellationToken);

    }

}

Μπορείτε να επιστρέψετε μια προσαρμοσμένη απόκριση χρησιμοποιώντας οποιαδήποτε από τις βοηθητικές μεθόδους της κλάσης ApiController που αναφέρονται παρακάτω.

Εντάξει

Δεν βρέθηκε

Εξαίρεση

Ανεξουσιοδότητος

BadRequest

σύγκρουση

Διευθύνω πάλιν

Μη έγκυροModelState

Επιστροφή απόκρισης από μεθόδους ελεγκτή WebAPI

Σε αυτήν την ενότητα θα διερευνήσουμε πώς μπορούμε να αξιοποιήσουμε το IHttpActionResult για την αποστολή απαντήσεων από τις μεθόδους του ελεγκτή.

Τώρα, εξετάστε τον ακόλουθο ελεγκτή WebApi:

δημόσια τάξη DefaultController: ApiController

    {

ιδιωτικό αναγνωστικό αποθετήριο DemoRepository = νέο DemoRepository ();

δημόσιο HttpResponseMessage Get (int id)

        {

var result = repository.GetData (id);

αν (αποτέλεσμα! = μηδέν)

Επιστροφή Request.CreateResponse (HttpStatusCode.OK, αποτέλεσμα);

Επιστροφή Request.CreateResponse (HttpStatusCode.NotFound);

        }

    }

Σημειώστε ότι ο κατάλληλος κωδικός κατάστασης επιστρέφεται σε κάθε περίπτωση, δηλαδή, εάν υπάρχουν διαθέσιμα δεδομένα, το HttpStatusCode.OK επιστρέφεται ενώ το HttpStatusCode.NotFound επιστρέφεται εάν τα δεδομένα δεν είναι διαθέσιμα.

Ας δούμε τώρα πώς μπορεί να αλλάξει η ίδια μέθοδος ελεγκτή για να επιστρέψει η απόκριση με το IHttpActionResult. Ακολουθεί ο ενημερωμένος κώδικας της μεθόδου ελέγχου για την αναφορά σας Σημειώστε πώς αντικαταστάθηκε το HttpResponseMessage με το IHttpActionResult.

δημόσια IHttpActionResult Get (int id)

        {

var result = repository.GetData (id);

εάν (αποτέλεσμα == null)

επιστροφή NotFound ();

επιστροφή ΟΚ (αποτέλεσμα)

        }

Ανατρέξτε στη μέθοδο λήψης που δίνεται παραπάνω. Ο κώδικας είναι πολύ απλός και λιτός και αφαιρεί τον τρόπο με τον οποίο το μήνυμα Http κατασκευάζεται πραγματικά στον ελεγκτή. Και, εδώ είναι ένα άλλο παράδειγμα.

Ανατρέξτε στο ακόλουθο απόσπασμα κώδικα που επιστρέφει το HttpResponseMessage για να αναφέρει επιτυχία ή αποτυχία.

δημόσια Διαγραφή HttpResponseMessage (int id)

        {

var status = repository.Delete (id);

εάν (κατάσταση)

επιστρέψτε νέο HttpResponseMessage (HttpStatusCode.OK);

επιστροφή νέου HttpResponseMessage (HttpStatusCode.NotFound);

        }

Τώρα δείτε πώς μπορεί να γίνει επαναπροσδιορισμός της ίδιας μεθόδου δράσης χρησιμοποιώντας το IHttpActionResult για να κάνετε τον κώδικα πολύ πιο λιτό και απλό.

δημόσια Διαγραφή IHttpActionResult (int id)

        {

var status = repository.Delete (id);

εάν (κατάσταση)

επιστροφή ΟΚ ();

επιστροφή NotFound ();

        }

Ποιο πρέπει να χρησιμοποιήσω και γιατί;

Επομένως, πρέπει να χρησιμοποιήσουμε το IHttpActionResult over HttpResponseMessage στους ελεγκτές WebAPI όταν στέλνουμε πίσω τις απαντήσεις; Αυτή είναι η απάντησή μου σε αυτήν την ερώτηση. Θα προτιμούσα πάντα το IHttpActionResult σε σχέση με το HttpResponseMessage, καθώς με αυτόν τον τρόπο, οι δοκιμές μονάδας των ελεγκτών θα απλοποιηθούν. Μπορείτε να μετακινήσετε την κοινή λογική για τη δημιουργία αποκρίσεων Http σε άλλες κατηγορίες και να κάνετε τις μεθόδους του ελεγκτή σας λιτές και απλές. Στην ουσία, οι λεπτομέρειες χαμηλού επιπέδου για τη δημιουργία των απαντήσεων Http θα ενσωματωθούν.

Σε διαφορετική σημείωση, αξίζει να σημειωθεί ότι κατά τη χρήση του IHttpActionResult, μπορείτε να συμμορφωθείτε με την αρχή της ενιαίας ευθύνης, καθώς και οι μέθοδοι δράσης σας μπορούν να επικεντρωθούν στη διαχείριση των αιτημάτων Http αντί να δημιουργήσετε τα μηνύματα απόκρισης Http Υπάρχει ένα άλλο σημείο που αξίζει να αναφερθεί. Μπορείτε να επωφεληθείτε από το IHttpActionResult για να παρέχετε υποστήριξη για HTML με το ξυράφι. Το μόνο που χρειάζεται να κάνετε είναι να δημιουργήσετε ένα αποτέλεσμα προσαρμοσμένης ενέργειας που μπορεί να αναλύσει τις προβολές του ξυραφιού. Η δημιουργία προσαρμοσμένου αποτελέσματος δράσης είναι απλή. Θα χρειαστεί απλώς να επεκτείνετε τη διεπαφή IHttpActionResult και, στη συνέχεια, να εφαρμόσετε τη δική σας έκδοση της μεθόδου ExecuteAsync.

$config[zx-auto] not found$config[zx-overlay] not found