วิธีการ RESTful API; HEAD & OPTIONS


97

ฉันกำลังเขียนโมดูล RESTful API สำหรับแอปพลิเคชันใน PHP และฉันผสมกับคำกริยาHEADและOPTIONS.

  • OPTIONS  ใช้เพื่อดึงคำกริยา HTTP ที่มีอยู่สำหรับทรัพยากรที่กำหนด?
  • HEAD ใช้เพื่อพิจารณาว่าทรัพยากรที่ระบุพร้อมใช้งานหรือไม่

หากมีใครสามารถชี้แจง * คำกริยาเหล่านี้ได้นั่นจะได้รับการชื่นชมมาก

* การชี้แจงเป็นไปตามสถาปัตยกรรม RESTful API ที่ใช้คำกริยา HTTP ซ้ำ ตั้งแต่นั้นมาฉันได้ตระหนักว่าทั้งสองอย่างHEADและไม่OPTIONSควรถูกนำมาใช้ซ้ำและแทนที่จะทำงานอย่างคาดเดาได้ตามที่แอปพลิเคชัน HTTP ควร โอ้เราเติบโตอย่างไรใน 2 ปี


อาจเป็นเพราะข้อมูลจำเพาะ HTTP พร้อมใช้งานบนเว็บ
Gordon

@Gordon - พอใช้ได้และในขณะที่ฉันเข้าใจว่าบริการ RESTful API มีจุดประสงค์เพื่อใช้ประโยชน์จากข้อกำหนด HTTP ที่มีอยู่ แต่ฉันเดาว่าฉันสันนิษฐานว่ามีการเบี่ยงเบนบางส่วนสำหรับรายละเอียดการใช้งาน ความผิดฉันเอง.
Dan Lugg

15
ข้อมูลจำเพาะสำหรับทุกสิ่งส่วนใหญ่พร้อมใช้งานบนเว็บ คำถามเกี่ยวกับ SO มีไว้เพื่อความกระจ่างนอกเหนือจากเอกสารประกอบ นี้เหมาะกับที่
Andrew Ensley

คำตอบ:


62

ตาม: http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

9.2 ตัวเลือก

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

การตอบสนองต่อวิธีนี้ไม่สามารถแคชได้

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

หาก Request-URI เป็นเครื่องหมายดอกจัน ("*") คำขอ OPTIONS มีวัตถุประสงค์เพื่อใช้กับเซิร์ฟเวอร์โดยทั่วไปแทนที่จะใช้กับทรัพยากรเฉพาะ เนื่องจากโดยทั่วไปแล้วตัวเลือกการสื่อสารของเซิร์ฟเวอร์จะขึ้นอยู่กับทรัพยากรคำขอ "*" จึงมีประโยชน์ในรูปแบบของวิธีการ "ping" หรือ "no-op" เท่านั้น ไม่ได้ทำอะไรเลยนอกจากอนุญาตให้ไคลเอ็นต์ทดสอบความสามารถของเซิร์ฟเวอร์ ตัวอย่างเช่นสามารถใช้เพื่อทดสอบพร็อกซีสำหรับการปฏิบัติตาม HTTP / 1.1 (หรือไม่มี)

ถ้า Request-URI ไม่ใช่เครื่องหมายดอกจันคำขอ OPTIONS จะใช้กับตัวเลือกที่พร้อมใช้งานเมื่อสื่อสารกับทรัพยากรนั้นเท่านั้น

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

ฟิลด์ส่วนหัวคำขอ Max-Forwards อาจใช้เพื่อกำหนดเป้าหมายพร็อกซีเฉพาะในห่วงโซ่คำขอ เมื่อพร็อกซีได้รับคำร้องขอ OPTIONS บน AbsoluteURI ที่อนุญาตให้ส่งต่อคำขอพร็อกซีต้องตรวจสอบฟิลด์ Max-Forwards หากค่าฟิลด์ Max-Forwards เป็นศูนย์ ("0") พร็อกซีต้องไม่ส่งต่อข้อความ แทนพร็อกซีควรตอบสนองด้วยตัวเลือกการสื่อสารของตัวเอง ถ้าค่าฟิลด์ Max-Forwards เป็นจำนวนเต็มมากกว่าศูนย์พร็อกซีต้องลดค่าฟิลด์เมื่อส่งต่อคำขอ หากไม่มีฟิลด์ Max-Forwards อยู่ในคำขอคำขอที่ส่งต่อจะต้องไม่รวมฟิลด์ Max-Forwards

9.4 หัว

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

การตอบสนองต่อคำขอ HEAD อาจแคชได้ในแง่ที่ว่าข้อมูลที่อยู่ในการตอบกลับอาจถูกใช้เพื่ออัปเดตเอนทิตีที่แคชไว้ก่อนหน้านี้จากทรัพยากรนั้น หากค่าฟิลด์ใหม่ระบุว่าเอนทิตีที่แคชแตกต่างจากเอนทิตีปัจจุบัน (ตามที่ระบุโดยการเปลี่ยนแปลงในความยาวของเนื้อหา, เนื้อหา -MD5, ETag หรือ Last-Modified) แคชจะต้องถือว่ารายการแคชเป็นข้อมูลเก่า


1
ขอบคุณ @sdolgy สำหรับคำพูดที่ครอบคลุม อย่างไรก็ตามในทางปฏิบัติ ( ควร ) โมดูล RESTful API ที่ประสบความสำเร็จจำนวนมากเป็นไปตามมาตรฐาน HTTP เหล่านี้ทั้งหมดหรือมีการตอบสนองแบบบางที่ยอมรับได้สำหรับการดำเนินการเหล่านี้หรือไม่ ไม่ใช่จากความเกียจคร้าน แต่เป็นเพียงความอยากรู้อยากเห็น ฉันจะใช้ทุกสิ่งที่จำเป็นในการปฏิบัติตาม
Dan Lugg

2
หากคุณกำลังสร้างของคุณเองซึ่งฉันคิดว่าคุณเป็นคุณควรพยายามรักษาความสอดคล้องกับมาตรฐานที่บันทึกไว้เพื่อให้ชีวิตของคุณง่ายขึ้น ... และคนที่ใช้ API ของคุณ ... อย่าติดตาม Microsoft RFC เป็นสิ่งที่ดีที่จะสอดคล้องกับ
sdolgy

ขอบคุณ @sdolgy เมื่อสรุปเอกสารที่เชื่อมโยงแล้วฉันสังเกตเห็นในตอนท้ายของCONNECTคำกริยา เป็นทางเลือกที่ไม่ดีที่จะใช้วิธีการนั้นสำหรับการตรวจสอบสิทธิ์ RESTful หรือไม่
Dan Lugg

ไม่แน่ใจว่าเป็นจุดประสงค์ที่ตั้งใจไว้ "ข้อกำหนดนี้ขอสงวนชื่อวิธีการ CONNECT สำหรับใช้กับพร็อกซีที่สามารถเปลี่ยนไปใช้อุโมงค์แบบไดนามิก (เช่น SSL tunneling [44])" ... อาจเป็นประโยชน์ในการโพสต์คำถามอื่นในคำถามหนึ่ง ของเว็บไซต์ stackexchange.com เกี่ยวกับเรื่องนี้ ...
sdolgy

2
@DanLugg แอปพลิเคชันของคุณอาจไม่ได้ใช้CONNECTในลักษณะของ SSL tunneling แต่ลองนึกดูว่าจะเกิดอะไรขึ้นหากผู้บริโภคแอปพลิเคชันของคุณมีพร็อกซีที่ใช้งานCONNECTตามวิธีที่ระบุไว้ใน RFC คำขออาจไม่ถูกส่งต่อไปยัง ใบสมัคร
Steve Buzonas

92

OPTIONSวิธีส่งคืนข้อมูลเกี่ยวกับAPI (วิธีการ / ประเภทเนื้อหา)

HEADวิธีการส่งคืนข้อมูลเกี่ยวกับทรัพยากร (เวอร์ชัน / ความยาว / ประเภท)

การตอบสนองของเซิร์ฟเวอร์

ตัวเลือก

HTTP/1.1 200 OK
Allow: GET,HEAD,POST,OPTIONS,TRACE
Content-Type: text/html; charset=UTF-8
Date: Wed, 08 May 2013 10:24:43 GMT
Content-Length: 0

ศีรษะ

HTTP/1.1 200 OK
Accept-Ranges: bytes
Content-Type: text/html; charset=UTF-8
Date: Wed, 08 May 2013 10:12:29 GMT
ETag: "780602-4f6-4db31b2978ec0"
Last-Modified: Thu, 25 Apr 2013 16:13:23 GMT
Content-Length: 1270
  • OPTIONS การระบุวิธีการ HTTP ที่ทรัพยากรรองรับเช่นเราสามารถลบหรืออัปเดตผ่านทาง PUT ได้หรือไม่
  • HEADตรวจสอบว่าทรัพยากรมีการเปลี่ยนแปลงหรือไม่ สิ่งนี้มีประโยชน์เมื่อรักษาเวอร์ชันแคชของทรัพยากร
  • HEAD การดึงข้อมูลเมตาเกี่ยวกับทรัพยากรเช่นประเภทสื่อหรือขนาดของทรัพยากรก่อนที่จะทำการดึงข้อมูลที่มีค่าใช้จ่ายสูง
  • HEAD, OPTIONSการทดสอบว่าทรัพยากรมีอยู่และสามารถเข้าถึงได้หรือไม่ ตัวอย่างเช่นการตรวจสอบความถูกต้องของลิงก์ที่ผู้ใช้ส่งมาในแอปพลิเคชัน

นี่คือบทความที่ดีและกระชับเกี่ยวกับการที่ HEAD และ OPTIONS เข้ากับสถาปัตยกรรม RESTful


9
คำตอบที่ดีเลวร้ายเกินไปที่จะต้องจ่ายค่าปรับที่ล่าช้าต่อพรรค คำตอบที่ยอมรับโดยการคัดลอกวางไม่ได้เริ่มต้นที่จะกล่าวถึงตำแหน่งของคำกริยาเหล่านี้ในสถาปัตยกรรม RESTful โดยเฉพาะ
Todd Menier

1
ลิงก์ของคุณหมดแล้ว นี่คือภาพรวมล่าสุด: web.archive.org/web/20160528151316/https://…
kolobok

31

OPTIONS จะบอกคุณถึงสิ่งต่างๆเช่น "วิธีใดที่อนุญาตให้ใช้ทรัพยากรนี้"

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


ขอบคุณ @Quentin; OPTIONSคือสิ่งที่ฉันคิดได้และการใช้งานดังกล่าวจะง่ายด้วยแนวทางที่มีอยู่ของฉัน ตามใบเสนอราคา RFC ของ sdolgy OPTIONSกำหนดว่าไม่มีมาตรฐานในรูปแบบ สันนิษฐานว่ารูปแบบการตอบกลับเหมือนกับการตอบกลับอื่น ๆ หรือไม่ ( เช่น; JSON, XML ฯลฯ )
Dan Lugg

@ Tomcat การอ้างถึง RFC: "การเจรจาเนื้อหาอาจใช้เพื่อเลือกรูปแบบการตอบกลับที่เหมาะสม" กล่าวอีกนัยหนึ่ง: การตอบสนองควรเป็นสิ่งที่คำขอขอในส่วนหัว
Gordon
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.