שני הסנטים שלי לשימוש בממשק IHttpActionResult ב- WebAPI

ה- WebAPI של מיקרוסופט מהווה מזה זמן מה את המסגרת הנבחרת לבניית שירותים RESTful שיכולים לעבוד באמצעות HTTP. ממשק IHttpActionResult הוצג עם WebAPI גרסה 2 ומספק דרך אחרת להחזיר תגובות משיטות הבקר של WebAPI שלך, והוא ממנף אסינכרון ומחכה כברירת מחדל.

בעיקרו של דבר, IHttpActionResult הוא מפעל ל- HttpResponsemessage. ממשק IHttpActionResult כלול במרחב השמות System.Web.Http ויוצר מופע של HttpResponseMessage בצורה סינכרונית. ה- IHttpActionResult כולל אוסף של תגובות מובנות בהתאמה אישית הכוללות: Ok, BadRequest, Exception, Conflict, Redirect, NotFound ו- Unorhorized.

ממשק IHttpActionResult מכיל שיטה אחת בלבד. כך נראה ממשק זה:

namespace System.Web.Http

{

    public interface IHttpActionResult

    {

        Task ExecuteAsync(CancellationToken cancellationToken);

    }

}

אתה יכול להחזיר תגובה מותאמת אישית באמצעות כל אחת משיטות העוזר של מחלקת ApiController המפורטות להלן.

Ok

NotFound

Exception

Unauthorized

BadRequest

Conflict

Redirect

InvalidModelState

תגובה חוזרת משיטות בקרת WebAPI

בחלק זה נחקור כיצד אנו יכולים למנף את IHttpActionResult כדי להחזיר תגובות משיטות הבקר.

עכשיו שקול את בקר ה- WebApi הבא:

public class DefaultController : ApiController

    {

        private readonly DemoRepository repository = new DemoRepository();

        public HttpResponseMessage Get(int id)

        {

            var result = repository.GetData(id);

            if (result != null)

                return Request.CreateResponse(HttpStatusCode.OK, result);

            return Request.CreateResponse(HttpStatusCode.NotFound);

        }

    }

שים לב שקוד המצב המתאים מוחזר בכל מקרה, כלומר אם נתונים זמינים, מוחזר HttpStatusCode.OK ואילו HttpStatusCode.NotFound מוחזר אם נתונים אינם זמינים.

בואו נראה כעת כיצד ניתן לשנות את אותה שיטת בקר כדי להחזיר את התגובה כ- IHttpActionResult. הנה הקוד המעודכן של שיטת הבקר לעיונך. שים לב כיצד הוחלף HttpResponseMessage ל- IHttpActionResult.

public IHttpActionResult Get(int id)

        {

            var result = repository.GetData(id);

            if (result == null)

                return NotFound();

            return Ok(result);

        }

עיין בשיטת Get המפורטת לעיל. הקוד הוא פשוט ורזה והוא ממצה את האופן שבו מסר ה- Http בנוי בפועל בבקר. והנה דוגמא נוספת.

עיין בקטע הקוד הבא המחזיר את HttpResponseMessage לדיווח על הצלחה או כישלון.

public HttpResponseMessage Delete(int id)

        {

            var status = repository.Delete(id);

            if (status)

               return new HttpResponseMessage(HttpStatusCode.OK);

            return new HttpResponseMessage(HttpStatusCode.NotFound);

        }

כעת ראה כיצד ניתן לשחזר את אותה שיטת פעולה באמצעות IHttpActionResult כדי להפוך את הקוד להרבה ופשוט יותר.

public IHttpActionResult Delete(int id)

        {

            var status = repository.Delete(id);

            if (status)

              return Ok();

            return NotFound();

        }

באיזה מהם עלי להשתמש ולמה?

אז האם עלינו להשתמש ב- IHttpActionResult על פני HttpResponseMessage בבקרי ה- WebAPI שלנו בעת שליחת התגובות בחזרה? הנה התשובה שלי לשאלה זו. תמיד הייתי מעדיף את IHttpActionResult על פני HttpResponseMessage כמו שבכך, בדיקות היחידות של הבקרים יהפכו לפשוטות יותר. אתה יכול להזיז את ההיגיון הנפוץ ליצירת תגובות Http לשיעורים אחרים ולהפוך את שיטות הבקר שלך לרזות ופשוטות. בעיקרו של דבר, הפרטים ברמה הנמוכה של יצירת תגובות ה- Http יוחסמו.

בנימה אחרת, ראוי להזכיר שבשימוש ב- IHttpActionResult, תוכלו לעמוד בעקרון האחריות היחידה, כמו גם שיטות הפעולה שלכם יכולות להתמקד בטיפול בבקשות ה- Http במקום לבנות את הודעות התגובה של Http. יש עוד נקודה שכדאי להזכיר. אתה יכול לנצל את IHttpActionResult כדי לספק תמיכה ב- HTML עם Razor. כל שעליך לעשות הוא ליצור תוצאת פעולה מותאמת אישית שיכולה לנתח את תצוגות התער. יצירת תוצאת פעולה מותאמת אישית היא פשוטה. אתה רק צריך להרחיב את ממשק IHttpActionResult ואז ליישם את הגרסה שלך לשיטת ExecuteAsync.