ASP.NET webapi Interview Questions
1.0.0
คลิกถ้าคุณชอบโครงการ คำขอดึงได้รับการชื่นชมอย่างมาก ติดตามฉัน @kansiris87 เพื่อรับข้อมูลอัปเดตทางเทคนิค
| เลขที่ | คำถาม |
|---|---|
| 1 | [REST คืออะไร](#REST คืออะไร) |
| 2 | [อธิบายหลักการ REST?](#อธิบายหลักการ REST?) |
| 3 | [REST และ SOAP แตกต่างกันอย่างไร](#REST และ SOAP แตกต่างกันอย่างไร) |
| 4 | [ASP.NET WEB API คืออะไร](#ASP.NET WEB API คืออะไร) |
| 5 | [ทำไมต้องเลือก ASP.NET WEB API?](#ทำไมต้องเลือก ASP.NET WEB API?) |
| 6 | [ความแตกต่างระหว่าง WCF และ ASP.NET WEB API และ WCF REST และบริการเว็บคืออะไร](#ความแตกต่างระหว่าง WCF และ ASP.NET WEB API และ WCF REST และบริการเว็บคืออะไร) |
| 7 | [จะเลือกอันไหนระหว่าง WCF และ WEB API?](#อันไหนให้เลือกระหว่าง WCF และ WEB API?) |
| 8 | [ความแตกต่างระหว่าง ASP.NET MVC และ ASP.NET WEB API คืออะไร](#Hความแตกต่างระหว่าง ASP.NET MVC และ ASP.NET WEB API คืออะไร) |
| 9 | [คุณสามารถคืนมุมมองโดยใช้วิธี WEB API ได้หรือไม่](#คุณสามารถคืนมุมมองโดยใช้วิธี WEB API ได้หรือไม่) |
| 10 | [คุณสามารถเปลี่ยนชื่อการกระทำของ WEB API เช่น ASP.NET MVC ได้หรือไม่] (#คุณสามารถเปลี่ยนชื่อการกระทำของ WEB API เช่น ASP.NET MVC ได้หรือไม่) |
|1 | [คุณสามารถจำกัดวิธีดำเนินการของ WEB API ให้เรียกใช้โดย HTTP GET, POST, PUT หรือ DELETE เท่านั้นได้หรือไม่](#คุณสามารถจำกัดวิธีดำเนินการของ WEB API ให้เรียกใช้โดย HTTP GET, POST, PUT หรือ DELETE เท่านั้นได้หรือไม่)| |2 | [วิธีเรียก WEB API ใน ASP.NET MVC?](#วิธีเรียก WEB API ใน ASP.NET MVC?)| |3 | [การกำหนดเส้นทาง ASP.NET API แตกต่างจากการกำหนดเส้นทาง ASP.NET MVC อย่างไร](#การกำหนดเส้นทาง ASP.NET API แตกต่างจากการกำหนดเส้นทาง ASP.NET MVC อย่างไร)| |4 | [วิธีเปิดใช้งานการกำหนดเส้นทางแอตทริบิวต์ใน ASP.NET WEB API2?](#วิธีเปิดใช้งานการกำหนดเส้นทางแอตทริบิวต์ใน ASP.NET WEB API2?)| |5 | [วิธีกำหนดเส้นทางแอตทริบิวต์ใน ASP.NET WEB API2?](#วิธีกำหนดเส้นทางแอตทริบิวต์ใน ASP.NET WEB API2?)|
REST ย่อมาจาก Representational State Transfer นี่คือโปรโตคอลสำหรับการแลกเปลี่ยนข้อมูลผ่านสภาพแวดล้อมแบบกระจาย REST เป็นรูปแบบสถาปัตยกรรมที่ปฏิบัติต่อแต่ละบริการเสมือนเป็นทรัพยากรและเข้าถึงข้อมูลด้วยวิธีโปรโตคอล HTTP เช่น GET, POST, PUT และ DELETE
สถาปัตยกรรมสไตล์ REST ประกอบด้วยไคลเอนต์และเซิร์ฟเวอร์ ลูกค้าเริ่มต้นคำขอไปยังเซิร์ฟเวอร์ที่ประมวลผลคำขอเหล่านี้และตอบกลับตามคำขอเหล่านี้ คำขอและการตอบกลับเหล่านี้สร้างขึ้นจากการถ่ายโอนการเป็นตัวแทนของทรัพยากรเหล่านี้
REST คือชุดหลักการที่กำหนดวิธีการใช้มาตรฐานเว็บ เช่น HTTP และ URI มีหลักการ REST ที่สำคัญห้าประการตามที่ระบุด้านล่าง -
ทรัพยากรที่สามารถระบุที่อยู่ได้ - ทรัพยากรแต่ละรายการควรได้รับการระบุโดย URI (ตัวระบุที่ไม่ซ้ำกัน)
อินเทอร์เฟซที่เรียบง่ายและสม่ำเสมอ - REST ใช้โปรโตคอล HTTP ดังนั้นให้ใช้วิธี HTTP GET, POST, PUT และ DELETE เพื่อดำเนินการ สิ่งนี้ทำให้ REST เรียบง่ายและสม่ำเสมอ
Representation Oriented- การเป็นตัวแทนของทรัพยากรมีการแลกเปลี่ยน GET ใช้เพื่อส่งคืนการเป็นตัวแทนและ PUT POST ผ่านการเป็นตัวแทนไปยังเซิร์ฟเวอร์เพื่อให้ทรัพยากรพื้นฐานอาจเปลี่ยนแปลงได้ การแสดงอาจมีหลายรูปแบบ เช่น XML, JSON เป็นต้น
สื่อสารไร้สัญชาติ - แอปพลิเคชันอาจมีสถานะ แต่ไม่มีข้อมูลเซสชันไคลเอ็นต์เก็บไว้บนเซิร์ฟเวอร์ ข้อมูลเฉพาะเซสชันใด ๆ ควรถูกเก็บรักษาและดูแลรักษาโดยไคลเอนต์ และถ่ายโอนไปยังเซิร์ฟเวอร์พร้อมคำขอแต่ละรายการตามความจำเป็น
แคชได้ - ไคลเอ็นต์ควรจะสามารถแคชการตอบสนองเพื่อใช้ต่อไปได้
ความแตกต่างระหว่าง REST และ SOAP แสดงไว้ด้านล่าง SOAP REST SOAP ย่อมาจาก Simple Object Access Protocol REST ย่อมาจาก REpresentational State Transfer เป็นโปรโตคอลที่ใช้ XML ที่สร้างขึ้นบน HTTP หรือบางครั้ง TCP/IP, SMTP REST ไม่ใช่โปรโตคอล แต่เป็นสถาปัตยกรรมแบบสถาปัตยกรรมตามทรัพยากร SOAP มีข้อกำหนดสำหรับการใช้งานทั้งแบบไร้สัญชาติและแบบมีสถานะ REST ไม่มีสถานะโดยสมบูรณ์ SOAP บังคับใช้รูปแบบข้อความเป็น XML REST ไม่บังคับใช้รูปแบบข้อความเป็น XML หรือ JSON SOAP มีข้อกำหนดมาตรฐานที่กำหนดไว้ ตัวอย่างเช่น WS-Security เป็นข้อกำหนดสำหรับการดำเนินการรักษาความปลอดภัย ไม่มีข้อกำหนดมาตรฐานที่กำหนดไว้ ข้อความ SOAP ประกอบด้วยซองจดหมายซึ่งประกอบด้วยส่วนหัวและเนื้อหา SOAP เพื่อเก็บข้อมูลจริงที่คุณต้องการส่ง REST ใช้ส่วนหัวบิวด์อิน HTTP (ที่มีประเภทสื่อหลากหลาย) เพื่อส่งข้อมูลเมตาและใช้กริยา GET, POST, PUT และ DELETE เพื่อดำเนินการ CRUD SOAP ใช้อินเทอร์เฟซและการดำเนินการที่กำหนดชื่อเพื่อเปิดเผยบริการของคุณ REST ใช้ URI และวิธีการเช่น (GET, PUT, POST, DELETE) เพื่อแสดงทรัพยากร ประสิทธิภาพช้าเมื่อเทียบกับ REST REST นั้นเร็วเมื่อเปรียบเทียบกับ SOAP
ASP.NET WEB API เป็นเฟรมเวิร์กสำหรับการสร้างบริการ HTTP ที่สามารถใช้งานได้โดยไคลเอนต์ที่หลากหลาย รวมถึงเบราว์เซอร์ โทรศัพท์มือถือ iPhone และแท็บเล็ต มันคล้ายกับ ASP.NET MVC มากเนื่องจากมีคุณสมบัติ MVC เช่น การกำหนดเส้นทาง ตัวควบคุม ผลลัพธ์การดำเนินการ ตัวกรอง ตัวประสานโมเดล คอนเทนเนอร์ IOC หรือการฉีดขึ้นต่อกัน แต่ไม่ได้เป็นส่วนหนึ่งของ MVC Framework เป็นส่วนหนึ่งของแพลตฟอร์ม ASP.NET หลักและสามารถใช้ได้กับ MVC และเว็บแอปพลิเคชันประเภทอื่นๆ เช่น ASP.NET WebForms นอกจากนี้ยังสามารถใช้เป็นแอปพลิเคชันบริการเว็บแบบสแตนด์อโลนได้ คุณสมบัติ ASP.NET WEB API 1. รองรับการดำเนินการ CRUD ตามแบบแผนเนื่องจากทำงานร่วมกับกริยา HTTP GET, POST, PUT และ DELETE 2. การตอบกลับมีส่วนหัว Accept และรหัสสถานะ HTTP 3. การตอบกลับจะถูกจัดรูปแบบโดย MediaTypeFormatter ของ WEB API เป็น JSON, XML หรือรูปแบบใดก็ตามที่คุณต้องการเพิ่มเป็น MediaTypeFormatter 4. อาจยอมรับและสร้างเนื้อหาที่อาจไม่ใช่เชิงวัตถุ เช่น รูปภาพ ไฟล์ PDF เป็นต้น 5. มีการสนับสนุน OData โดยอัตโนมัติ ดังนั้นด้วยการวางแอตทริบิวต์ [Queryable] ใหม่บนวิธีการควบคุมที่ส่งคืน IQueryable ไคลเอ็นต์จะสามารถใช้วิธีการสำหรับองค์ประกอบแบบสอบถาม OData ได้ 6. สามารถโฮสต์ได้ในแอปพลิเคชันหรือบน IIS 7. นอกจากนี้ยังรองรับคุณสมบัติ MVC เช่น การกำหนดเส้นทาง ตัวควบคุม ผลลัพธ์การดำเนินการ ตัวกรอง ตัวประสานโมเดล คอนเทนเนอร์ IOC หรือการฉีดขึ้นต่อกันที่ทำให้ง่ายขึ้นและแข็งแกร่งยิ่งขึ้น
ปัจจุบัน แอปพลิเคชันบนเว็บไม่เพียงพอที่จะเข้าถึงลูกค้า ผู้คนฉลาดมาก พวกเขาใช้อุปกรณ์ iPhone, มือถือ, แท็บเล็ต ฯลฯ ในชีวิตประจำวัน อุปกรณ์เหล่านี้ยังมีแอปมากมายที่ทำให้ชีวิตง่ายขึ้น จริงๆ แล้ว เรากำลังย้ายจากเว็บไปสู่โลกของแอพ
ดังนั้น หากคุณต้องการเปิดเผยข้อมูลบริการของคุณไปยังเบราว์เซอร์และแอปอุปกรณ์สมัยใหม่เหล่านี้ด้วยวิธีที่รวดเร็วและง่ายดาย คุณควรมี API ที่เข้ากันได้กับเบราว์เซอร์และอุปกรณ์เหล่านี้ทั้งหมด
ตัวอย่างเช่น twitter, facebook และ Google API สำหรับแอปพลิเคชันเว็บและแอปโทรศัพท์
WEB API เป็นเฟรมเวิร์กที่ยอดเยี่ยมสำหรับการเปิดเผยข้อมูลและบริการของคุณไปยังอุปกรณ์ที่แตกต่างกัน นอกจากนี้ WEB API ยังเป็นโอเพ่นซอร์สซึ่งเป็นแพลตฟอร์มที่เหมาะสำหรับการสร้างบริการ REST-ful บน .NET Framework ต่างจากบริการ WCF Rest ตรงที่ใช้คุณสมบัติครบถ้วนของ HTTP (เช่น URI, ส่วนหัวคำขอ/ตอบกลับ, แคช, การกำหนดเวอร์ชัน และรูปแบบเนื้อหาต่างๆ) และคุณไม่จำเป็นต้องกำหนดการตั้งค่าเพิ่มเติมใดๆ สำหรับอุปกรณ์ต่างๆ ซึ่งไม่เหมือนกับบริการ WCF Rest
หากเราต้องการ Web Service และไม่ต้องการ SOAP ASP.NET WEB API ก็เป็นตัวเลือกที่ดีที่สุด
ใช้เพื่อสร้างบริการ HTTP แบบเรียบง่ายที่ไม่ใช่ SOAP บนไปป์ไลน์ข้อความ WCF ที่มีอยู่
ไม่มีการกำหนดค่าที่น่าเบื่อและกว้างขวางเช่นบริการ WCF REST
การสร้างบริการอย่างง่ายด้วย WEB API ด้วย WCF REST Services การสร้างบริการจึงทำได้ยาก
ขึ้นอยู่กับ HTTP เท่านั้น และง่ายต่อการกำหนด เปิดเผย และใช้งานในลักษณะ REST
เป็นสถาปัตยกรรมน้ำหนักเบาและดีสำหรับอุปกรณ์ที่มีแบนด์วิธจำกัด เช่น สมาร์ทโฟน
มันเป็นโอเพ่นซอร์ส
.NET Framework มีเทคโนโลยีมากมายที่ช่วยให้คุณสามารถสร้างบริการ HTTP ได้ เช่น Web Service, WCF และปัจจุบันคือ WEB API มีความแตกต่างดังต่อไปนี้ในสี่สิ่งนี้:
บริการเว็บ
ขึ้นอยู่กับ SOAP และส่งคืนข้อมูลในรูปแบบ XML
รองรับโปรโตคอล HTTP เท่านั้น
ไม่ใช่โอเพ่นซอร์ส แต่สามารถใช้ได้โดยไคลเอนต์ที่เข้าใจ xml
สามารถโฮสต์ได้เฉพาะบน IIS เท่านั้น
WCF
นอกจากนี้ยังขึ้นอยู่กับ SOAP และส่งคืนข้อมูลในรูปแบบ XML
เป็นวิวัฒนาการของบริการเว็บ (ASMX) และรองรับโปรโตคอลต่างๆ เช่น TCP, HTTP, HTTPS, Named Pipes, MSMQ
ปัญหาหลักของ WCF คือการกำหนดค่าที่น่าเบื่อและกว้างขวาง
ไม่ใช่โอเพ่นซอร์ส แต่สามารถใช้ได้โดยไคลเอนต์ที่เข้าใจ xml
สามารถโฮสต์ได้ในแอปพลิเคชันหรือบน IIS หรือใช้บริการหน้าต่าง
WCF ส่วนที่เหลือ
หากต้องการใช้ WCF เป็นบริการ WCF Rest คุณต้องเปิดใช้งาน webHttpBindings
รองรับกริยา HTTP GET และ POST โดยแอตทริบิวต์ [WebGet] และ [WebInrigg] ตามลำดับ
หากต้องการเปิดใช้งานกริยา HTTP อื่น ๆ คุณต้องทำการกำหนดค่าบางอย่างใน IIS เพื่อยอมรับคำขอของกริยานั้นในไฟล์ .svc
การส่งผ่านข้อมูลผ่านพารามิเตอร์โดยใช้ WebGet จำเป็นต้องมีการกำหนดค่า ต้องระบุ UriTemplate
รองรับรูปแบบข้อมูล XML, JSON และ ATOM
เว็บ API
นี่คือเฟรมเวิร์กใหม่สำหรับการสร้างบริการ HTTP ด้วยวิธีที่ง่ายและสะดวก
WEB API เป็นแพลตฟอร์มโอเพ่นซอร์สที่เหมาะสำหรับการสร้างบริการ REST-ful บน .NET Framework
ต่างจากบริการ WCF Rest ตรงที่ใช้คุณสมบัติครบถ้วนของ HTTP (เช่น URI, ส่วนหัวคำขอ/ตอบกลับ, แคช, การกำหนดเวอร์ชัน, รูปแบบเนื้อหาต่างๆ)
นอกจากนี้ยังรองรับฟีเจอร์ MVC เช่น การกำหนดเส้นทาง ตัวควบคุม ผลลัพธ์การดำเนินการ ตัวกรอง ตัวประสานโมเดล คอนเทนเนอร์ IOC หรือการฉีดการพึ่งพา การทดสอบหน่วยที่ทำให้ง่ายและแข็งแกร่งยิ่งขึ้น
สามารถโฮสต์ได้ในแอปพลิเคชันหรือบน IIS
เป็นสถาปัตยกรรมน้ำหนักเบาและดีสำหรับอุปกรณ์ที่มีแบนด์วิธจำกัด เช่น สมาร์ทโฟน
การตอบกลับจะถูกจัดรูปแบบโดย MediaTypeFormatter ของ WEB API เป็น JSON, XML หรือรูปแบบใดก็ตามที่คุณต้องการเพิ่มเป็น MediaTypeFormatter
ประเด็นต่อไปนี้ช่วยให้คุณเลือกระหว่าง WCF และ WEB API:
เลือก WCF เมื่อคุณต้องการสร้างบริการที่ควรสนับสนุนสถานการณ์พิเศษ เช่น การส่งข้อความทางเดียว คิวข้อความ การสื่อสารสองทาง เป็นต้น
เลือก WCF เมื่อคุณต้องการสร้างบริการที่สามารถใช้ช่องทางการขนส่งที่รวดเร็วเมื่อมีให้บริการ เช่น TCP, Named Pipes หรือแม้แต่ UDP (ใน WCF 4.5) และคุณยังต้องการรองรับ HTTP เมื่อช่องทางการขนส่งอื่นๆ ทั้งหมดไม่พร้อมใช้งาน
เลือก WEB API เมื่อคุณต้องการสร้างบริการที่มุ่งเน้นทรัพยากรผ่าน HTTP ที่สามารถใช้คุณสมบัติครบถ้วนของ HTTP (เช่น URI, ส่วนหัวคำขอ/ตอบกลับ, การแคช, การกำหนดเวอร์ชัน, รูปแบบเนื้อหาต่างๆ)
เลือก WEB API เมื่อคุณต้องการเปิดเผยบริการของคุณกับไคลเอนต์ที่หลากหลาย รวมถึงเบราว์เซอร์ โทรศัพท์มือถือ iPhone และแท็บเล็ต
มีความแตกต่างระหว่าง ASP.NET MVC และ WEB API ดังต่อไปนี้:
ASP.NET MVC ใช้เพื่อสร้างเว็บแอปพลิเคชันที่ส่งคืนทั้งมุมมองและข้อมูล แต่ ASP.NET WEB API ใช้เพื่อสร้างบริการ HTTP เต็มรูปแบบด้วยวิธีที่ง่ายและสะดวกซึ่งส่งคืนเฉพาะข้อมูลที่ไม่ได้ดู
WEB API ช่วยในการสร้างบริการ REST-ful บน .NET Framework และยังสนับสนุนการเจรจาต่อรองเนื้อหา (เกี่ยวกับการตัดสินใจเลือกข้อมูลรูปแบบการตอบสนองที่ดีที่สุดที่ไคลเอนต์อาจยอมรับได้ อาจเป็น JSON, XML, ATOM หรือข้อมูลที่จัดรูปแบบอื่น ๆ ) การโฮสต์ด้วยตนเองซึ่งไม่ได้อยู่ใน MVC
WEB API ยังดูแลการส่งคืนข้อมูลในรูปแบบเฉพาะ เช่น JSON, XML หรืออื่น ๆ ตามส่วนหัว Accept ในคำขอ และคุณไม่ต้องกังวลกับเรื่องนั้น MVC ส่งคืนข้อมูลในรูปแบบ JSON โดยใช้ JsonResult เท่านั้น
ใน WEB API คำขอจะถูกแมปกับการกระทำตามกริยา HTTP แต่ใน MVC คำขอจะถูกแมปกับชื่อการกระทำ
ASP.NET WEB API เป็นเฟรมเวิร์กใหม่และเป็นส่วนหนึ่งของเฟรมเวิร์ก ASP.NET หลัก การผูกโมเดล ตัวกรอง การกำหนดเส้นทาง และคุณสมบัติ MVC อื่นๆ ที่มีอยู่ใน WEB API นั้นแตกต่างจาก MVC และมีอยู่ในแอสเซมบลี System.Web.Http ใหม่ ใน MVC คุณสมบัติเหล่านี้มีอยู่ใน System.Web.Mvc ดังนั้น WEB API ยังสามารถใช้กับ ASP.NET และเป็นชั้นบริการแบบสแตนด์อโลนได้
คุณสามารถผสมตัวควบคุม WEB API และ MVC ในโปรเจ็กต์เดียวเพื่อจัดการคำขอ AJAX ขั้นสูงซึ่งอาจส่งคืนข้อมูลในรูปแบบ JSON, XML หรือรูปแบบอื่น ๆ และสร้างบริการ HTTP เต็มรูปแบบ โดยทั่วไปจะเรียกว่าการโฮสต์ด้วยตนเองของ WEB API
เมื่อคุณผสมตัวควบคุม MVC และ WEB API และคุณต้องการใช้การอนุญาต คุณจะต้องสร้างตัวกรองสองตัว ตัวหนึ่งสำหรับ MVC และอีกตัวสำหรับ WEB API เนื่องจากทั้งสองต่างกัน
นอกจากนี้ WEB API ยังเป็นสถาปัตยกรรมน้ำหนักเบา และยกเว้นเว็บแอปพลิเคชันที่สามารถใช้กับแอปสมาร์ทโฟนได้
ต่างจาก ASP.NET MVC ตรงที่ WEB API ใช้เพื่อส่งคืนข้อมูลเท่านั้น ข้อมูลสามารถเป็นสตริง, JSON, XML, ข้อความ ฯลฯ ไม่สามารถส่งคืน View เช่น ASP.NET MVC
เช่นเดียวกับ ASP.NET MVC คุณสามารถเปลี่ยนชื่อการกระทำของ WEB API ได้โดยใช้แอตทริบิวต์ ActionName ดังที่ระบุด้านล่าง:
[HttpGet] [ActionName("GetProducts")] สาธารณะ IEnumerable ProductList() { return db.Products.AsEnumerable(); -
เช่นเดียวกับ ASP.NET MVC คุณยังสามารถจำกัดวิธีดำเนินการของ WEB API ที่จะเรียกใช้โดยคำขอ HTTP ที่ระบุเท่านั้น โดยใช้แอตทริบิวต์ HttpGet หรือ HttpPost หรือ HttpPut หรือ HttpDelete
หากคุณต้องการจำกัดวิธีดำเนินการสำหรับคำขอ HTTP Get เท่านั้น ให้ตกแต่งมันด้วยแอตทริบิวต์ตัวเลือกวิธีการกระทำ HttpGet ดังที่ระบุด้านล่าง:
[HttpGet] สาธารณะ IEnumerable ProductList () { กลับ db.Products.AsEnumerable (); -
ASP.NET WEB API สามารถเรียกได้โดยใช้ที่อยู่ HttpClient และ WEB API ตามที่ระบุด้านล่าง:
ProductController ระดับสาธารณะ: ตัวควบคุม { ไคลเอนต์ HttpClient = ใหม่ HttpClient (); Uri BaseAddress = Uri ใหม่ ("http://localhost:131/"); ดัชนี ActionResult สาธารณะ () { Client.BaseAddress = BaseAddress; การตอบสนอง HttpResponseMessage = Client.GetAsync("productservice/GetProducts").ผลลัพธ์; ถ้า (response.IsSuccessStatusCode) { var data = response.Content.ReadAsAsync<IEnumerable>().Result; กลับดู (ข้อมูล); } กลับดู(); -
ASP.NET MVC และ ASP.NET WEB API ทั้งคู่ใช้การกำหนดเส้นทางเพื่อตรวจสอบคำขอที่เข้ามาและมีการกำหนดเส้นทางอย่างน้อยหนึ่งเส้นทางเพื่อให้สามารถทำงานได้ ความแตกต่างระหว่างเส้นทางทั้งสองนี้ได้รับด้านล่าง:
ในพารามิเตอร์รูปแบบเส้นทาง WEB API {action} เป็นทางเลือก แต่คุณสามารถรวมพารามิเตอร์ {action} ได้ ใน ASP.NET MVC {action} จำเป็นต้องมีพารามิเตอร์
วิธีการดำเนินการที่กำหนดไว้ในตัวควบคุม API ต้องมีแอตทริบิวต์กริยาการกระทำ HTTP (GET, POST, PUT, DELETE) หรือมีกริยาการกระทำ HTTP อย่างใดอย่างหนึ่งเป็นคำนำหน้าสำหรับชื่อวิธีการดำเนินการ ใน ASP.NET MVC ตามค่าเริ่มต้น วิธีการดำเนินการสามารถเรียกได้ด้วยกริยา HTTP GET หรือ POST และสำหรับการใช้กริยา HTTP อื่น ๆ ที่คุณต้องกำหนดเป็นแอตทริบิวต์
ต่างจาก ASP.NET MVC ตรงที่ Web API สามารถรับประเภทที่ซับซ้อนได้เพียงประเภทเดียวเป็นพารามิเตอร์
การเปิดใช้งานการกำหนดเส้นทางแอตทริบิวต์ใน ASP.NET WEB API2 ของคุณนั้นง่ายดาย เพียงเพิ่มการเรียกไปยังเมธอด MapHttpAttributeRoutes() ด้วยเมธอด in Register() ของไฟล์ WebApiConfig.cs
WebApiConfig คลาสคงที่สาธารณะ { โมฆะสาธารณะลงทะเบียน (การกำหนดค่า HttpConfiguration) { // เปิดใช้งานการกำหนดเส้นทางแอตทริบิวต์ config.MapHttpAttributeRoutes (); -
คุณยังสามารถรวมการกำหนดเส้นทางแอตทริบิวต์เข้ากับการกำหนดเส้นทางตามแบบแผนได้ด้วย
WebApiConfig คลาสคงที่สาธารณะ { โมฆะสาธารณะคงที่การลงทะเบียน (การกำหนดค่า HttpConfiguration) {
//เปิดใช้งานการกำหนดเส้นทางแอตทริบิวต์ config.MapHttpAttributeRoutes(); // การกำหนดเส้นทางตามแบบแผน config.Routes.MapHttpRoute (ชื่อ: "DefaultApi",
เทมเพลตเส้นทาง: "api/{controller}/{id}" ค่าเริ่มต้น: ใหม่ { id = RouteParameter.Optional });
-
เช่นเดียวกับ ASP.NET MVC5 คุณยังสามารถกำหนดการกำหนดเส้นทางแอตทริบิวต์ใน WEB API2 ได้ที่ระดับคอนโทรลเลอร์และระดับการดำเนินการดังที่แสดงด้านล่าง:
[RoutePrefix ("บริการ / ผู้ใช้")] UserController ระดับสาธารณะ: ApiController { // GET เส้นทาง: api / User สาธารณะ IEnumerable Get () { ส่งคืนสตริงใหม่ [] { "value1", "value2" };
}
[เส้นทาง ("{id}")] // เส้นทาง GET: บริการ / ผู้ใช้ / 1 สตริงสาธารณะรับ (int id) { กลับ "ค่า"; -
[เส้นทาง ("")] // เส้นทาง POST: บริการ / ผู้ใช้ / โมฆะสาธารณะโพสต์ (ค่าสตริง [FromBody]) { } }
• การกำหนดเส้นทางระดับการดำเนินการ – คุณสามารถกำหนดเส้นทางในระดับการดำเนินการซึ่งจะนำไปใช้กับการดำเนินการเฉพาะในตัวควบคุม
UserController คลาสสาธารณะ: ApiController { //GET เส้นทาง: api/User
สาธารณะ IEnumerable Get () { คืนสตริงใหม่ [] { "value1", "value2" };
-
[เส้นทาง ("บริการ / ผู้ใช้ / {id}")] // เส้นทาง GET: บริการ / ผู้ใช้ / 1 สตริงสาธารณะรับ (int id) { กลับ "ค่า"; } [เส้นทาง ("บริการ/ผู้ใช้/")] // เส้นทาง POST: บริการ/ผู้ใช้/ โมฆะสาธารณะ โพสต์ (ค่าสตริง [FromBody]) { } }
