คำถามและคำตอบสัมภาษณ์ REST API ยอดนิยม

RESTful API มีการพัฒนาหลายอย่าง รวมถึงการ ประมวลผลแบบคลาวด์ และสถาปัตยกรรมที่ใช้ไมโครเซอร์วิส พวกเขาแสดงให้เห็นการสื่อสารออนไลน์และคอมพิวเตอร์เป็นเรื่องง่าย ดังนั้น นักพัฒนาทุกคนจะต้องเข้าใจ ว่า REST คือ อะไร ทำงานอย่างไร ประโยชน์อย่างไร และจะสร้างบริการที่ปลอดภัยเพื่อให้ทันกับเวลาได้อย่างไร เนื่องจากอาจช่วยพวกเขาในการสร้างโซลูชันที่ปรับขนาดได้ บำรุงรักษาง่าย และทำให้ผลิตภัณฑ์ของตนเข้าถึงคนทั้งโลกได้ด้วยพลังของอินเทอร์เน็ต ธุรกิจจำนวนมากจึงชอบนักพัฒนาที่เข้าใจ REST

จะเตรียมตัวสำหรับคำถามสัมภาษณ์เกี่ยวกับ RESTful API ได้อย่างไร

คำถามสัมภาษณ์ REST API ที่พบบ่อยที่สุดเกี่ยวกับบริการเว็บ RESTful ในระหว่างการสัมภาษณ์ REST API และคำถามเกี่ยวกับไลบรารี JAX-RS และบริการเว็บ RESTful ที่สร้างขึ้นโดยใช้เฟรมเวิร์ก Spring MVC ถูกกล่าวถึงในส่วนด้านล่าง ก่อนนั่งหรือนัดสัมภาษณ์ การเตรียมตัวสำหรับคำถามสัมภาษณ์ REST API ที่กล่าวถึงทั้งหมดเป็นสิ่งสำคัญ

REST คืออะไร?

REST ซึ่งอธิบายถึงการโอนสถานะการเป็นตัวแทนมีหน้าที่รับผิดชอบในการพัฒนาแอปเว็บไซต์ที่สร้างบนโปรโตคอล HTTP REST ระบุกฎหลายข้อที่ต้องแนบประโยชน์ที่เกี่ยวข้องกับเว็บไซต์เพื่อให้เชื่อได้ คำแนะนำช่วยให้มั่นใจถึงวิธีการ HTTP ที่ได้มาตรฐานระหว่างเซิร์ฟเวอร์และผู้ใช้ในการส่งสิ่งที่ส่งมาแบบเสมือนจริง

REST API คืออะไร

RESTful API ทำให้การแลกเปลี่ยนข้อมูลออนไลน์อย่างปลอดภัยระหว่างระบบคอมพิวเตอร์สองระบบ เพื่อทำกิจกรรมที่หลากหลาย แอปพลิเคชันทางธุรกิจ ส่วนใหญ่จะแลกเปลี่ยนข้อมูลกับโปรแกรมภายในและภายนอกอื่นๆ ตัวอย่างเช่น เมื่อระบบบัญชีภายในของคุณแชร์ข้อมูลพนักงานกับระบบธนาคารภายนอกเพื่อสร้างสลิปเงินเดือน สามารถทำได้ด้วย REST API เนื่องจากข้อมูลนี้เป็นข้อมูลส่วนตัวส่วนบุคคล และมาตรฐานซอฟต์แวร์ REST API นั้นปลอดภัย มีประสิทธิภาพ และเชื่อถือได้

RESTful API เรียกว่า API ที่เชื่อมโยงกับ REST ไม่ทางใดก็ทางหนึ่ง ข้อมูลทั้งหมดถือเป็นทรัพยากรใน REST API และกำหนดโดยหน่วยค่าคงที่มาตรฐานที่เรียกว่า (URI) Twitter API สร้างทวีตเป็นทรัพยากรที่ผู้ใช้สามารถเข้าถึงและเรียกคืนได้ การใช้ Twitter API ผู้ใช้สามารถเผยแพร่ทวีตได้อย่างง่ายดาย

หลักการของ REST คืออะไร?

เซิร์ฟเวอร์ไคลเอนต์อนุญาตให้มีลำดับการตอบสนองที่ใช้ในการส่งระหว่างผู้บริโภคและเซิร์ฟเวอร์ ทั้งคู่สามารถส่งและรับการตอบกลับจากกันและกันได้ การมองเห็นที่ชัดเจนของวิธีการแบบไคลเอ็นต์-เซิร์ฟเวอร์จะช่วยให้กองกำลังทั้งสองทำงานโดยไม่ได้รับความช่วยเหลือจากกันและกัน

ระบบเลเยอร์

ระหว่างไคลเอนต์และเซิร์ฟเวอร์ API เลเยอร์คือเซิร์ฟเวอร์ เซิร์ฟเวอร์ที่แตกต่างกันเหล่านี้ทำงานหลายอย่าง เช่น ตรวจจับสแปมและปรับปรุงประสิทธิภาพ ข้อความที่ส่งระหว่างไคลเอ็นต์และเซิร์ฟเวอร์ Application Programming Interface (API) จะไม่ได้รับผลกระทบจากการเพิ่มหรือลบเลเยอร์ เนื่องจาก REST (สถานะตัวแทน) ใช้สถาปัตยกรรมโมดูลาร์

อินเตอร์เฟซที่สม่ำเสมอ

ไคลเอนต์และเซิร์ฟเวอร์ต้องใช้โปรโตคอลที่เหมือนกันเสมอสำหรับการสื่อสารทั้งหมด โปรโตคอลนี้คือ HTTP REST เนื่องจากทุกแอปพลิเคชันใช้ภาษาเดียวกันในการร้องขอและให้ข้อมูล อินเทอร์เฟซแบบเดียวกันจึงอำนวยความสะดวกในการผสานรวม

ไร้สัญชาติ

ในการสื่อสารไร้สัญชาติ เซิร์ฟเวอร์จะไม่เก็บบันทึกการตอบกลับที่ส่งไปแล้ว ทุกคำตอบมีข้อมูลครบถ้วนที่จำเป็นในการสรุปข้อตกลง ปรับปรุงการตีความโดยลดภาระของเซิร์ฟเวอร์และการใช้หน่วยความจำ นอกจากนี้ยังยกเลิกโอกาสที่คำขออาจล้มเหลวเนื่องจากข้อมูลไม่ครบถ้วน

แคชได้

ไคลเอนต์สามารถแคชทรัพยากรใด ๆ เพื่อเพิ่มประสิทธิภาพโดยใช้คำตอบของเซิร์ฟเวอร์จากเซิร์ฟเวอร์ที่ระบุว่าทรัพยากรนั้นสามารถแคชได้หรือไม่ REST ยังมีเงื่อนไขเพิ่มเติมดังต่อไปนี้

โค้ดออนดีมานด์

การตอบสนองของ API สามารถมีรหัสปฏิบัติการที่ผู้ใช้สามารถเรียกใช้ได้ ดังนั้น แอปพลิเคชันไคลเอนต์สามารถรันโค้ดที่ส่วนหลังของมันเอง

AJAX และ REST ต่างกันอย่างไร

ความแตกต่างระหว่าง AJAX และ REST คือ:

สถาปัตยกรรมไมโครเซอร์วิสทำงานอย่างไร

วิธีการทางสถาปัตยกรรมสำหรับการพัฒนาแอปพลิเคชันระบบคลาวด์เรียกว่าไมโครเซอร์วิส แต่ละแอปพลิเคชันประกอบด้วยบริการต่างๆ มากมาย ซึ่งแต่ละบริการดำเนินการในกระบวนการที่แยกจากกันและโต้ตอบกับบริการอื่นๆ ผ่าน API วิธีการสร้างแอปพลิเคชันที่เรียกว่า "สถาปัตยกรรมไมโครเซอร์วิส" ได้กลายเป็นแนวปฏิบัติที่ดีที่สุดเมื่อเวลาผ่านไป ส่วนประกอบของสถาปัตยกรรม microservice ขึ้นอยู่กับความต้องการของธุรกิจ

• ลูกค้า

ผู้ใช้จำนวนมากส่งคำขอโดยใช้อุปกรณ์ต่างๆ

• ผู้ให้บริการข้อมูลประจำตัว

ตรวจสอบตัวตนของผู้ใช้หรือลูกค้าและจัดเตรียมโทเค็นความปลอดภัย

• เกตเวย์ API

คำขอของลูกค้าได้รับการจัดการผ่าน API Gateway

• เนื้อหาคงที่

วัสดุทั้งหมดของระบบมีอยู่ในเนื้อหาคงที่

• การจัดการ

กำหนดความล้มเหลวและความสมดุลของบริการข้ามโหนด

• การค้นพบบริการ

เครื่องมือสำหรับกำหนดเส้นทางการสื่อสารระหว่างไมโครเซอร์วิส

• เครือข่ายการจัดส่งเนื้อหา

เครือข่ายแบบกระจายของพร็อกซีเซิร์ฟเวอร์และศูนย์ข้อมูลที่เกี่ยวข้อง

• บริการระยะไกล

ข้อมูลที่จัดเก็บไว้ในเครือข่ายของอุปกรณ์ไอทีสามารถเข้าถึงได้จากระยะไกลด้วยความช่วยเหลือของบริการระยะไกล

HTTP เมธอดใดบ้างที่ REST รองรับ

เมธอดที่รองรับ REST HTTP คือ:

• GET - วิธีที่ใช้กันอย่างแพร่หลายมากที่สุดในเว็บไซต์และ API GET รับทรัพยากรจากเซิร์ฟเวอร์ข้อมูลเฉพาะ
• POST - ด้วยวิธี POST ข้อมูลจะถูกส่งไปยังเซิร์ฟเวอร์ API เพื่ออัปเดตทรัพยากร เมื่อเซิร์ฟเวอร์ได้รับข้อมูล จะจัดเก็บไว้ในเนื้อหาคำขอ HTTP
• PUT - ส่งข้อมูลไปยัง API เพื่อสร้างและอัปเดตทรัพยากร
• DELETE - ตามชื่อที่แนะนำ วิธีนี้ใช้เพื่อลบทรัพยากรที่ URL ที่ระบุ
• ตัวเลือก - ให้รายละเอียดเทคนิคที่รองรับ

HEAD - ข้อมูลเมตาเกี่ยวกับ URL คำขอจะถูกส่งกลับ ลองตรวจสอบสถานการณ์จากมุมมองของเรกคอร์ดเดียว สมมติว่ามีบันทึกของพนักงานที่มีพนักงานหมายเลข 1 แต่ละกิจกรรมต่อไปนี้จะระบุบางสิ่งที่แตกต่างกัน

POST - เนื่องจากเรากำลังดึงข้อมูลของพนักงาน 1 ซึ่งถูกสร้างขึ้นแล้ว จึงใช้ไม่ได้

GET - จะใช้เพื่อดึงข้อมูลของพนักงานผ่าน RESTful web API และหมายเลขพนักงานจะเป็น 1

PUT - การใช้ RESTful web API PUT จะถูกใช้เพื่ออัปเดตข้อมูลของพนักงานเพื่อสะท้อนถึงพนักงานหมายเลข 1

ลบ - ฟังก์ชันนี้ใช้เพื่อลบข้อมูลพนักงานด้วยหมายเลขพนักงาน 1

PUT กับ POST ต่างกันอย่างไร?

ความแตกต่างระหว่าง PUT และ Post มีดังนี้:

• PUT - ระบุไฟล์หรือทรัพยากรอย่างแม่นยำและโดยเฉพาะอย่างยิ่งที่ URI ที่ให้มา (ตัวระบุทรัพยากรแบบเดียวกัน) PUT แก้ไขไฟล์ที่มีอยู่หากมีอยู่ที่ตัวระบุทรัพยากรที่เป็นเอกภาพ - URI PUT จะสร้างไฟล์ถ้ามีอยู่แล้ว นอกจากนี้ PUT ยังเป็น idempotent โดยบอกว่าไม่ส่งผลกระทบต่อไฟล์ แต่ความถี่ในการใช้งานเป็นอย่างไร
• POST - ส่งข้อมูลไปยังตัวระบุทรัพยากรแบบเดียวกัน - URI และคาดว่าไฟล์ทรัพยากรจะจัดการความต้องการ ในขณะนี้ เซิร์ฟเวอร์ของเว็บไซต์สามารถตัดสินใจได้ว่าจะทำอย่างไรกับข้อมูลในบริบทของไฟล์ที่เลือก นอกจากนี้ กลยุทธ์ POST นั้นไม่ได้ไร้ประสิทธิภาพ ซึ่งหมายความว่าหากคุณใช้งานมากกว่าหนึ่งครั้ง ระบบจะสร้างไฟล์ใหม่ต่อ

อะไรคือความแตกต่างระหว่าง Monolithic SOA และ Microservices Architecture?

แอ ปขนาดใหญ่มีอัตราการพัฒนาที่ช้ามากและประกอบด้วยหน่วยที่เชื่อมต่อระหว่างกันและแบ่งแยกไม่ได้ บริการที่เล็กกว่าและเชื่อมต่อน้อยที่สุดประกอบกันเป็น SOA ซึ่งมีการพัฒนาอย่างจำกัดเช่นกัน

Microservices มีขนาดเล็กอย่างไม่น่าเชื่อ เชื่อมต่ออย่างหลวมๆ เป็นบริการแบบสแตนด์อโลนที่มีวงจรการพัฒนาซ้ำอย่างรวดเร็ว

URI คืออะไร?

ตัวระบุทรัพยากรแบบเดียวกันเรียกว่า URI URI ใน REST เป็นสตริงที่กำหนดทรัพยากรของเว็บเซิร์ฟเวอร์ ทรัพยากรแต่ละรายการมี URI ที่แตกต่างกัน ซึ่งเมื่อใช้ในคำขอ HTTP จะทำให้ไคลเอนต์สามารถกำหนดเป้าหมายและดำเนินการกับทรัพยากรนั้นได้ การกำหนดที่อยู่คือกระบวนการกำหนดทิศทางการรับส่งข้อมูลไปยังทรัพยากรโดยใช้ URI

รูปแบบของ URI คือ:

<โปรโตคอล>://<ชื่อบริการ>/<ResourceType>/<ResourceID>

URI มีสองประเภท

1. URL - ข้อมูลเกี่ยวกับการดึงทรัพยากรจากตำแหน่งของทรัพยากรมีอยู่ใน Uniform Resource Locator

URL มีข้อมูลเกี่ยวกับชื่อโฮสต์เครือข่าย (sampleServer.com) และเส้นทางไปยังเนื้อหา (/samplePage.html) และเริ่มต้นด้วยโปรโตคอล (เช่น FTP, HTTP เป็นต้น) นอกจากนี้ยังอาจมีเกณฑ์การค้นหา

2. URN - โดยใช้ชื่อที่ทั้งโดดเด่นและคงทน ชื่อรีซอร์สที่เหมือนกันจะระบุรีซอร์ส

URN ไม่จำเป็นต้องระบุตำแหน่งของทรัพยากรบนอินเทอร์เน็ต พวกเขาทำหน้าที่เป็นแบบจำลองสำหรับโปรแกรมแยกวิเคราะห์อื่น ๆ ที่จะใช้เมื่อระบุทรัพยากร

เมื่อใดก็ตามที่ URN ระบุเอกสาร สามารถแปลงเป็น URL ได้อย่างรวดเร็วโดยใช้ "ตัวแก้ไข" เพื่อให้สามารถดาวน์โหลดได้

คุณลักษณะของ RESTful Web Services คืออะไร?

คุณสมบัติเหล่านี้มีอยู่ในทุกบริการบนเว็บ RESTful:

• โมเดลการสื่อสารระหว่างไคลเอ็นต์กับเซิร์ฟเวอร์เป็นรากฐานของบริการ
• บริการนี้ใช้โปรโตคอล HTTP เพื่อดึงข้อมูล/ทรัพยากร รันการสืบค้น และทำงานอื่นๆ
• "ข้อความ" เป็นวิธีการสื่อสารระหว่างไคลเอ็นต์และเซิร์ฟเวอร์
• บริการสามารถเข้าถึงทรัพยากรผ่าน URIs
• เป็นไปตามแนวคิดเรื่องการไร้สัญชาติ ซึ่งคำขอและคำตอบของลูกค้าจะไม่ขึ้นอยู่กับผู้อื่น ดังนั้นจึงให้ความมั่นใจอย่างสมบูรณ์ว่าจะได้รับข้อมูลที่จำเป็น
• เพื่อลดการเรียกใช้เซิร์ฟเวอร์สำหรับคำขอซ้ำๆ ประเภทเดียวกัน บริการเหล่านี้ยังใช้แนวคิดของการแคช
• บริการเหล่านี้สามารถใช้รูปแบบสถาปัตยกรรม REST โดยใช้บริการ SOAP

รหัสสถานะ HTTP คืออะไร

รหัสมาตรฐานที่ใช้ในสถานะ HTTP สอดคล้องกับสถานะการเสร็จสิ้นงานเซิร์ฟเวอร์ที่กำหนดไว้ ตัวอย่างเช่น สถานะ HTTP 404 ระบุว่าเซิร์ฟเวอร์ไม่มีทรัพยากรที่ร้องขอ

ลองดูที่รหัสสถานะ HTTP และทำความเข้าใจความหมาย:

• 200 - ตกลง ความสำเร็จปรากฏชัด
• 201 - เมื่อคำขอ POST หรือ PUT สร้างทรัพยากรสำเร็จ รหัสตอบกลับคือ 201 - CREATED ใช้ส่วนหัวตำแหน่ง ส่งกลับ URL ไปยังทรัพยากรที่สร้างขึ้นใหม่
• 304 - ในกรณีของคำขอ GET แบบมีเงื่อนไข รหัสสถานะ 304 ไม่ถูกแก้ไขจะถูกใช้เพื่อประหยัดแบนด์วิธของเครือข่าย หน่วยงานตอบสนองต้องเป็นโมฆะ วันที่ สถานที่ และข้อมูลอื่นๆ ควรอยู่ในส่วนหัว
• 400 - BAD REQUEST ระบุว่ามีการป้อนข้อมูลที่ไม่ถูกต้อง เช่น ข้อมูลที่ขาดหายไปหรือข้อผิดพลาดในการตรวจสอบ
• 401 - FORBIDDEN ระบุว่าผู้ใช้ไม่มีสิทธิ์เข้าถึงวิธีการที่ใช้ เช่น การลบการเข้าถึงโดยไม่มีสิทธิ์ของผู้ดูแลระบบ
• 404 - ข้อผิดพลาดระบุว่าไม่พบวิธีการที่ร้องขอ
• 409 - ความขัดแย้ง เมื่อเมธอดถูกดำเนินการ มันบ่งชี้ถึงปัญหาที่ขัดแย้งกัน เช่น การแทรกรายการที่ซ้ำกัน
• 500 - รหัสข้อผิดพลาดเซิร์ฟเวอร์ภายในระบุว่าเซิร์ฟเวอร์ส่งข้อยกเว้นในขณะที่กำลังดำเนินการเมธอด

คุณช่วยบอกข้อเสียของบริการเว็บ RESTful ได้ไหม?

ข้อเสียของบริการเว็บ RESTful คือ:

• ไม่สามารถรักษาเซสชันในบริการเว็บ RESTful ได้เนื่องจากผู้ช่วยยึดติดกับแนวคิดเรื่องความไร้สัญชาติ
• ข้อจำกัดด้านความปลอดภัยและการป้องกันไม่จำเป็นต่อ REST โปรโตคอลบางอย่างใช้สำหรับการป้องกันความปลอดภัย การทำเช่นนี้จะเป็นการเตือนที่สามารถใช้งานในขณะที่กำหนดมาตรฐานการป้องกันและความปลอดภัยที่จะเลือก เช่น - การรับรองความถูกต้อง SSL/TLS

แยกความแตกต่างระหว่าง SOAP และ REST หรือไม่

ความแตกต่างระหว่าง SOAP และ REST คือ:

องค์ประกอบหลักของ HTTP Response คืออะไร

การตอบกลับ HTTP มีองค์ประกอบหลักสี่ส่วนดังต่อไปนี้:

Try AppMaster no-code today!

Platform can build any web, mobile or backend application 10x faster and 3x cheaper

Start Free

• รหัสสถานะการตอบกลับ - แสดงรหัสสถานะของเซิร์ฟเวอร์เพื่อตอบสนองคำขอทรัพยากร ตัวอย่าง: ข้อผิดพลาดฝั่งไคลเอ็นต์แสดงด้วย 400 ในขณะที่คำตอบที่สำเร็จแสดงด้วย 200
• เวอร์ชัน HTTP - เวอร์ชันโปรโตคอล HTTP ระบุโดยเวอร์ชัน HTTP
• ส่วนหัวการตอบสนอง - ข้อมูลเมตาของข้อความตอบกลับมีอยู่ในส่วนนี้ ข้อมูลสามารถใช้เพื่อระบุสิ่งต่างๆ เช่น ความยาวของเนื้อหา ประเภท วันที่ตอบกลับ ประเภทเซิร์ฟเวอร์ ฯลฯ
• เนื้อหาการตอบสนอง - ทรัพยากรหรือข้อความที่เซิร์ฟเวอร์ส่งคืนจริงมีอยู่ในเนื้อหาการตอบสนอง

WebSockets และ REST แตกต่างกันอย่างไร

นี่คือความแตกต่างบางประการระหว่าง WebSockets และ REST ที่กล่าวถึงด้านล่าง:

REST ขึ้นอยู่กับการดำเนินการของ CRUD ในขณะที่ WebSocket เป็นโปรโตคอลระดับต่ำตามแนวคิดของซ็อกเก็ตและพอร์ต ซึ่งเป็นกลไกการส่งข้อมูลพื้นฐาน

ในขณะที่แอปพลิเคชัน RESTful ต้องออกแบบการทำงานตามคำกริยาและ HTTP แต่ WebSocket ต้องการการใช้ที่อยู่ IP และข้อมูลพอร์ต ซึ่งเป็นรายละเอียดระดับล่างสำหรับแอปพลิเคชันใดๆ WebSocket เป็นโปรโตคอลแบบมีสถานะ ในขณะที่ REST สร้างขึ้นบนโปรโตคอลแบบไร้สถานะ หมายความว่าทั้งไคลเอนต์และเซิร์ฟเวอร์ไม่จำเป็นต้องรับรู้ซึ่งกันและกัน

ตรงกันข้ามกับ REST ซึ่งใช้ HTTP ซึ่งสามารถปรับขนาดในแนวนอนได้ การเชื่อมต่อ WebSocket สามารถปรับขนาดในแนวตั้งบนเซิร์ฟเวอร์เครื่องเดียว การสื่อสารที่ใช้ REST นั้นค่อนข้างแพงกว่า แต่การสื่อสารผ่าน WebSocket นั้นถูกกว่า

เราสามารถใช้ Transport Layer Security (TLS) ใน REST ได้หรือไม่

เราทำได้ ใช่! การสื่อสารของไคลเอ็นต์-เซิร์ฟเวอร์ใน REST นั้นได้รับการเข้ารหัสโดยใช้ TLS ซึ่งช่วยให้ผู้ใช้สามารถตรวจสอบเซิร์ฟเวอร์ได้ เนื่องจากมาแทนที่ Secure Socket Layer (SSL) จึงเป็นรูปแบบการสื่อสารที่ปลอดภัยระหว่างผู้ใช้และเซิร์ฟเวอร์ เนื่องจาก HTTPS ทำงานได้ดีกับ Secure Socket Layer (SSL) & Transport Layer Security (TLS) จึงมีประโยชน์เมื่อสร้างบริการเว็บ RESTful ที่นี่ สิ่งสำคัญคือต้องทราบว่า REST เป็นส่วนหนึ่งของโปรโตคอลที่ใช้ ดังนั้น การป้องกันความปลอดภัยจึงอาศัยโปรโตคอลของ REST

ขนาดเพย์โหลดสูงสุดที่สามารถส่งด้วยวิธี POST คือเท่าใด

ขนาดของน้ำหนักบรรทุกที่สามารถลำเลียงในวิธีการโพสต์นั้นไม่ถูกจำกัดในทางทฤษฎี อย่างไรก็ตาม สิ่งสำคัญคือต้องจำไว้ว่าเพย์โหลดที่มากขึ้นจะใช้แบนด์วิธมากขึ้นและใช้เวลาในการประมวลผลนานขึ้น ซึ่งส่งผลต่อการตอบสนองของเซิร์ฟเวอร์

แสดงรายการคำอธิบายประกอบหลักที่มีอยู่ใน JAX-RS API

• เส้นทาง - รายละเอียดเส้นทาง Uniform Resource Identifier (URI) ของทรัพยากร REST
• GET - ตัวกำหนดวิธีการร้องขอนี้สอดคล้องกับ HTTP GET พวกเขาจัดการแบบสอบถาม GET
• POST - ตัวกำหนดวิธีการร้องขอนี้สอดคล้องกับ HTTP POST พวกเขาจัดการกับคำถาม POST
• PUT - ตัวกำหนดวิธีการร้องขอนี้สอดคล้องกับคำขอ HTTP PUT พวกเขาจัดการกับคำถาม PUT
• DELETE - กำหนดเป็นตัวกำหนดสำหรับวิธีการร้องขอที่ใช้สำหรับ HTTP DELETE พวกเขาจัดการคำขอ DELETE
• HEAD - ตัวกำหนดวิธีการร้องขอนี้สอดคล้องกับ HTTP HEAD พวกเขาจัดการกับคำถามของ HEAD
• PathParam - นักพัฒนาสามารถใช้พารามิเตอร์พาธ Uniform Resource Identifier (URI) เพื่อแยกพารามิเตอร์จาก URI สำหรับคลาส/เมธอดทรัพยากร
• QueryParam - คลาส/เมธอดของรีซอร์สสามารถใช้เคียวรีเหล่านี้ที่ดึงมาจาก Uniform Resource Identifier (URI) โดยผู้พัฒนาโดยใช้พารามิเตอร์เคียวรี Uniform Resource Identifier (URI)
• ผลิต - งานนำเสนอทรัพยากร MIME ที่สร้างและส่งไปยังผู้ใช้เป็นการตอบกลับจะระบุไว้ที่นี่
• ใช้ - รายละเอียดการนำเสนอทรัพยากร MIME ที่เซิร์ฟเวอร์จะยอมรับหรือใช้เมื่อได้รับกลับจากผู้ใช้

กำหนด RestTemplate ใน Spring

คลาสหลักสำหรับการเข้าถึงบริการ RESTful ของผู้ใช้เรียกว่า RestTemplate การใช้ข้อจำกัดของ REST ทำให้สามารถสื่อสารกับเซิร์ฟเวอร์ได้ ซึ่งเปรียบได้กับส่วนเทมเพลตต่างๆ ที่ Spring นำเสนอ เช่น JdbcTemplate และ HibernateTemplate RestTemplate ช่วยให้เมธอดสามารถสื่อสารโดยใช้เท็มเพลต URI (Uniform Resource Identifier ) พาธ URI (Uniform Resource Identifier) ชนิดของคำขอ/การตอบกลับ ออบเจกต์คำขอ ฯลฯ ซึ่งจะให้รายละเอียดการใช้งานระดับสูงสำหรับเมธอด HTTP เช่น GET , POST , PUT ฯลฯ

ส่วนนี้จาก Spring 4.3 นำเสนอคำอธิบายประกอบที่ใช้บ่อย เช่น @GetMapping, PutMapping, @PostMapping เป็นต้น ก่อนหน้านั้น Spring เสนอการตีความ @RequestMapping เพื่อระบุวิธีการที่ใช้

การใช้งาน @RequestMapping คืออะไร?

• คำขอถูกแมปกับเมธอดตัวจัดการเฉพาะโดยใช้คำอธิบายประกอบ
• Dispatcher Servlet จัดการการกำหนดเส้นทางเว็บแอปพลิเคชันที่เข้ามาทั้งหมดใน Spring โดยการใช้ตัวจัดการคำขอ ระบบจะตัดสินใจว่าตัวควบคุมใดในบรรดาทั้งหมดที่มีจุดประสงค์เพื่อจัดการคำขอเมื่อได้รับ คลาสทั้งหมดที่มีคำอธิบายประกอบ @Controller จะถูกสแกนโดย Dispatcher Servlet
  คำอธิบายประกอบ @RequestMapping ซึ่งกำหนดไว้ในเมธอดและคลาสของคอนโทรลเลอร์ มีความสำคัญต่อกระบวนการกำหนดเส้นทางคำขอ

รายชื่อเครื่องมือหรือ API สำหรับการพัฒนาหรือทดสอบเว็บ API

ด้วยความช่วยเหลือของเครื่องมือต่างๆ เช่น Postman, Swagger เป็นต้น บริการเว็บ RESTful อาจได้รับการทดสอบ บุรุษไปรษณีย์มีคุณลักษณะมากมาย รวมถึงความสามารถในการส่งคำขอไปยังจุดสิ้นสุด แสดงการตอบกลับที่สามารถแปลงเป็น JSON หรือ XML และวิเคราะห์พารามิเตอร์คำขอ เช่น ส่วนหัวและพารามิเตอร์การค้นหา ตลอดจนส่วนหัวของการตอบสนอง เช่นเดียวกับบุรุษไปรษณีย์ Swagger มีฟังก์ชันมากมายรวมถึงความสามารถในการจัดทำเอกสาร ปลายทาง เรายังสามารถทดสอบประสิทธิภาพและโหลดของ API โดยใช้เครื่องมือเช่น Jmeter

แคชคืออะไร?

เมื่อมีการแคชการตอบสนองของเซิร์ฟเวอร์ ระบบจะบันทึกเพื่อให้สามารถใช้สำเนาใหม่ได้ทุกเมื่อที่จำเป็น แทนที่จะต้องสร้างการตอบกลับเดิมอีกครั้ง เทคนิคนี้ไม่เพียงแต่แบ่งเบาภาระบนเซิร์ฟเวอร์เท่านั้น แต่ยังปรับปรุงประสิทธิภาพและความสามารถในการปรับขยายอีกด้วย ไคลเอนต์สามารถแคชการตอบสนองได้เพียงชั่วขณะหนึ่งเท่านั้น

ส่วนหัวของทรัพยากรและคำอธิบายโดยย่อรวมอยู่ด้านล่างเพื่อให้ขั้นตอนการแคชสามารถระบุได้:

• วันที่และเวลาที่สร้างทรัพยากร
• วันที่และเวลาของการอัปเดตทรัพยากร ซึ่งโดยทั่วไปจะเก็บข้อมูลล่าสุดไว้
• ส่วนหัวสำหรับการควบคุมแคช
• วันที่และเวลาที่ทรัพยากรที่เก็บไว้จะหยุดทำงาน
• อายุที่กำหนดจุดเริ่มต้นเมื่อมีการดึงทรัพยากร

แหล่งข้อมูลที่ดีที่สุดในการเรียนรู้ REST API คืออะไร

มีแหล่งข้อมูลมากมายให้เรียนรู้ REST API สำหรับ การพัฒนาเว็บไซต์และแอปพลิเคชันบนมือถือ 5 อันดับแรกมีดังต่อไปนี้:

บริการเว็บ RESTful

เพื่อเริ่มต้นการพัฒนาแอปพลิเคชันที่มีการใช้ API คู่มือเล่มนี้ชื่อ RESTful Web Services wonder โดย Leonard Richardson จะเป็นประโยชน์อย่างยิ่งในเรื่องนี้ โดยเฉพาะอย่างยิ่งหากคุณเป็นมือใหม่และต้องการเข้าใจพื้นฐานของบริการเว็บไซต์ Regentational State Transfer (REST) แหล่งข้อมูลเปิดเผยว่า Regentational State Transfer (REST) ทำงานอย่างไรและบริการที่เกี่ยวข้องกับเว็บที่จำเป็นอื่นๆ พร้อมตัวอย่าง มันไม่ได้ขึ้นอยู่กับภาษาการเขียนโปรแกรมใด ๆ ดังนั้นความเข้าใจของ RESTful API จะไม่ผูกมัดกับภาษาโปรแกรมใด ๆ

บทช่วยสอน REST API

บทช่วยสอน REST API เป็นแหล่งข้อมูลออนไลน์ที่ยอดเยี่ยมสำหรับการเรียนรู้ Representational State Transfer (REST) หากคุณไม่ใช่นักอ่านหนังสือหรืออ่านหนังสือ ทรัพยากรนี้จะช่วยให้คุณเรียนรู้ REST ตั้งแต่ต้นจนจบ ครอบคลุมประเด็นพื้นฐานทั้งหมด บทช่วยสอนนี้เริ่มต้นด้วยการแนะนำ Representational State Transfer (REST) จากนั้นจะดำเนินตามเส้นทางของตัวอย่างเกี่ยวกับกลยุทธ์และความรู้ที่เกี่ยวข้องกับ HTTP และอื่นๆ

กฎการออกแบบ REST API

นี่เป็นหนังสือแหล่งข้อมูลที่ยอดเยี่ยมสำหรับแนวทาง Representational State Transfer (REST) เนื่องจาก Mark Masse ผู้เขียนหนังสือได้ถ่ายทอดประสบการณ์และกลยุทธ์ที่เขาใช้ซึ่งช่วยในการสร้างแอปพลิเคชันโดยใช้ REST API ในแหล่งข้อมูลนี้ เขาได้กล่าวถึงแนวทางปฏิบัติสำหรับการออกแบบ URI ของแอปพลิเคชัน วิธีการส่งข้อมูลเมตาผ่านส่วนหัว HTTP และประเภทของสื่อที่สามารถใช้ได้ นอกจากนี้ วิธีการเกี่ยวข้องกับนวัตกรรมในการออกแบบวิธีการส่งของ HTTP และรหัสสถานะการตอบสนอง

จดหมายข่าวนักพัฒนา API รายสัปดาห์

มีแหล่งข้อมูลที่ยอดเยี่ยมที่เรียกว่าจดหมายข่าวรายสัปดาห์สำหรับนักพัฒนา API; เป็นทรัพยากรที่ทันสมัยสำหรับการเรียนรู้ RESTful API เนื่องจากเน้นไปที่เทคนิค โครงสร้าง ส่วนขยาย และสถาปัตยกรรมของ API สำหรับแอปพลิเคชันบนเว็บและแอปบนอุปกรณ์เคลื่อนที่ จดหมายข่าวได้รับการออกแบบมาเป็นพิเศษสำหรับนักพัฒนา ผู้จัดการโครงการ และสถาปนิก

มั่นใจได้

อันนี้เป็นสื่อทดสอบ REST โอเพ่นซอร์สที่โชคดีสำหรับผู้ที่มีประสบการณ์กับภาษาโปรแกรมหนึ่งที่เรียกว่า Java แหล่งข้อมูลนี้ช่วยอำนวยความสะดวกในขั้นตอนการทดสอบและตรวจสอบความถูกต้องของกระบวนการ RESTful API REST-Asured ยังกำจัดความจำเป็นในการสร้างรหัสสำเร็จรูปสำหรับการทดสอบปฏิกิริยาที่ซับซ้อนและช่วยไวยากรณ์ BDD

โดยสังเขป

เพื่อเป็นการสรุป บทความที่กล่าวถึงข้างต้นจะแชร์คำถามสัมภาษณ์ REST API ครอบคลุมคำถามสัมภาษณ์ REST API ทั้งหมดสำหรับผู้ที่กำลังจะสมัครหรือเคยสมัครงานที่คล้ายกันซึ่งต้องการความรู้ RESTful API คำถามเหล่านี้เป็นคำถามที่พบบ่อยที่สุดที่ผู้สัมภาษณ์สามารถถามคุณระหว่างการสัมภาษณ์งาน นอกจากนี้ ตรวจสอบแหล่งข้อมูลที่กล่าวถึงก่อนที่คุณจะเข้ารับการสัมภาษณ์ขั้นสุดท้าย

นอกจากนี้ หากคุณต้องการสร้างแอปพลิเคชันเว็บไซต์หรือแอปมือถือ AppMaster สามารถเป็นตัวเลือกที่ดีที่สุดของคุณ เป็น แพลตฟอร์มที่ไม่ต้องใช้โค้ด ที่จะช่วยให้คุณสร้างแอปพลิเคชันได้ทุกประเภทด้วย วิธีลากและวางที่ ง่ายดาย และไม่จำเป็นต้องมีประสบการณ์หรือความรู้ด้านการเขียนโค้ดมาก่อน ตรวจสอบข้อเสนอวันนี้