REST API - เพราะเหตุใดจึงใช้ PUT DELETE POST GET

ดังนั้นฉันจึงดูบทความเกี่ยวกับการสร้าง REST API และบางคนก็แนะนำให้ใช้ทุกประเภทของการร้องขอ HTTP: PUT DELETE POST GETเช่น เราจะสร้างเช่นindex.phpและเขียน API ด้วยวิธีนี้:

$method = $_SERVER['REQUEST_METHOD'];
$request = split("/", substr(@$_SERVER['PATH_INFO'], 1));

switch ($method) {
  case 'PUT':
    ....some put action.... 
    break;
  case 'POST':
    ....some post action.... 
    break;
  case 'GET':
    ....some get action.... 
    break;
  case 'DELETE':
    ....some delete action.... 
    break;
}

ตกลงรับ - ฉันไม่ได้รู้มากเกี่ยวกับบริการเว็บ (ยัง) แต่จะไม่ง่ายกว่าที่จะยอมรับวัตถุJSONผ่านปกติPOSTหรือGET(ที่จะมีชื่อวิธีการและพารามิเตอร์ทั้งหมด) แล้วตอบสนองใน JSON เช่นกัน เราสามารถเป็นอันดับ / deserialize ผ่านของ PHP json_encode()และjson_decode()และทำสิ่งที่เราต้องการกับข้อมูลที่ได้โดยไม่ต้องมีการจัดการกับวิธีการร้องขอ HTTP ที่แตกต่างกัน

ฉันพลาดอะไรไปรึเปล่า?

อัปเดต 1:

ตกลงหลังจากขุด API ต่างๆและเรียนรู้มากมายเกี่ยวกับXML-RPC , JSON-RPC , SOAP , RESTฉันได้ข้อสรุปว่า API ประเภทนี้มีเสียง อันที่จริงการแลกเปลี่ยนสแต็คสวยมากใช้วิธีการนี้ในเว็บไซต์ของพวกเขาและฉันไม่คิดว่าคนเหล่านี้รู้ว่าสิ่งที่พวกเขากำลังทำStack แลกเปลี่ยน API

ความคิดของRE presentational S tate T ransfer ไม่ได้เกี่ยวกับการเข้าถึงข้อมูลในวิธีที่ง่ายที่สุดที่เป็นไปได้

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

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

ตัวอย่างเช่น:

GET: /cars/make/chevrolet

มีแนวโน้มว่าจะส่งคืนรายการรถยนต์ chevy api REST ที่ดีอาจรวมเอาท์พุทตัวเลือกบางอย่างในการสืบค้นเช่น?output=jsonหรือ?output=htmlซึ่งจะอนุญาตให้ผู้เข้าถึงตัดสินใจว่าควรจะเข้ารหัสรูปแบบข้อมูลใด

หลังจากที่บิตของความคิดเกี่ยวกับวิธีการพิมพ์ข้อมูล incorporate สมควรเป็น REST API ผมได้ข้อสรุปว่าวิธีที่ดีที่สุดเพื่อระบุชนิดของข้อมูลที่ชัดเจนจะผ่านนามสกุลไฟล์ที่มีอยู่แล้วเช่น.js, .json, หรือ.html .xmlนามสกุลไฟล์ที่ขาดหายไปจะใช้ค่าเริ่มต้นเป็นรูปแบบใดก็ได้ที่เป็นค่าเริ่มต้น (เช่น JSON) นามสกุลไฟล์ที่ไม่รองรับสามารถส่งคืน501 Not Implementedรหัสสถานะได้

ตัวอย่างอื่น:

POST: /cars/
{ make:chevrolet, model:malibu, colors:[red, green, blue, grey] }

มีแนวโน้มที่จะสร้าง chevy malibu ใหม่ในฐานข้อมูลด้วยสีที่เกี่ยวข้อง ฉันบอกว่าน่าจะเป็นเพราะ REST API ไม่จำเป็นต้องเกี่ยวข้องโดยตรงกับโครงสร้างฐานข้อมูล มันเป็นเพียงส่วนติดต่อแบบกำบังเพื่อให้ข้อมูลจริงได้รับการปกป้อง (คิดว่ามันเหมือนกับ accessors และ mutators สำหรับโครงสร้างฐานข้อมูล)

ตอนนี้เราต้องย้ายไปยังปัญหาของidempotence โดยปกติ REST จะใช้CRUDผ่าน HTTP HTTP ใช้GET, PUT, POSTและDELETEสำหรับการร้องขอ

การใช้งาน REST อย่างง่ายสามารถใช้การแมป CRUD ต่อไปนี้:

Create -> Post
Read   -> Get
Update -> Put
Delete -> Delete

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

ซึ่งหมายความว่าคำขอเช่น:

Delete: /cars/oldest

สามารถนำมาใช้จริงเป็น:

Post: /cars/oldest?action=delete

แต่ทว่า

Delete: /cars/id/123456

จะส่งผลให้เซิร์ฟเวอร์อยู่ในสถานะเดียวกันหากคุณเรียกมันครั้งเดียวหรือถ้าคุณเรียกมันว่า 1,000 ครั้ง

วิธีที่ดีกว่าในการจัดการการลบoldestรายการจะเป็นการร้องขอ:

Get: /cars/oldest

และใช้ข้อมูลIDจากผลลัพธ์เพื่อทำการdeleteร้องขอ:

Delete: /cars/id/[oldest id]

ปัญหาเกี่ยวกับวิธีการนี้จะเกิดขึ้นหาก/carsมีการเพิ่มรายการอื่นระหว่างเมื่อ/oldestมีการร้องขอและเมื่อมีการdeleteออก

นี่คือคำถามความปลอดภัยและการบำรุงรักษา

วิธีการที่ปลอดภัย

เมื่อใดก็ตามที่เป็นไปได้คุณควรใช้วิธี 'ปลอดภัย' (ทิศทางเดียว) เช่น GET และ HEAD เพื่อ จำกัด ช่องโหว่ที่อาจเกิดขึ้น

วิธีการ idempotent

เมื่อใดก็ตามที่เป็นไปได้คุณควรใช้วิธี 'idempotent' เช่น GET, HEAD, PUT และ DELETE ซึ่งไม่สามารถมีผลข้างเคียงดังนั้นจึงเกิดข้อผิดพลาดน้อยลง / ควบคุมง่ายกว่า

แหล่ง

ในระยะสั้น REST เน้นคำนามมากกว่าคำกริยา เมื่อ API ของคุณซับซ้อนมากขึ้นคุณจะต้องเพิ่มสิ่งต่างๆมากกว่าที่จะเป็นคำสั่ง

คุณถามว่า :

จะไม่ง่ายกว่าเพียงแค่ยอมรับวัตถุ JSON ผ่าน $ _POST ปกติแล้วตอบกลับด้วย JSON เช่นกัน

จาก Wikipedia บนREST :

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

จากสิ่งที่ฉันเห็น (น้อย) ฉันเชื่อว่าสิ่งนี้มักจะสำเร็จได้ด้วยการใช้คำกริยา HTTP ที่มีอยู่ให้มากที่สุดและออกแบบโครงร่าง URL สำหรับบริการของคุณที่ทรงพลังและชัดเจนที่สุดเท่าที่จะทำได้

โปรโตคอลข้อมูลที่กำหนดเอง (แม้ว่าพวกเขาจะถูกสร้างขึ้นบนสุดของคนมาตรฐานเช่น SOAP หรือ JSON) จะหมดกำลังใจและควรจะลดให้สอดคล้องกับอุดมการณ์ REST ที่ดีที่สุด

SOAP RPC ผ่าน HTTP ในทางกลับกันกระตุ้นให้ผู้ออกแบบแอปพลิเคชันแต่ละคนกำหนดคำศัพท์และคำกริยาใหม่และตามอำเภอใจ (ตัวอย่างเช่น getUsers (), savePurchaseOrder (... )) ซึ่งมักจะวางทับคำกริยา HTTP 'POST' สิ่งนี้ไม่คำนึงถึงความสามารถที่มีอยู่ของ HTTP เช่นการรับรองความถูกต้องการแคชและการเจรจาต่อรองประเภทเนื้อหาและอาจทำให้นักออกแบบแอปพลิเคชันได้คิดค้นคุณลักษณะเหล่านี้ใหม่อีกมากมาย

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

คุณถาม :

ฉันพลาดอะไรไปรึเปล่า?

มีอะไรอีกมากมายที่ต้องรู้เกี่ยวกับ REST และไวยากรณ์ของ URI / HTTP กริยาด้วยตัวเอง ตัวอย่างเช่นคำกริยาบางคำเป็น idempotent แต่บางคำก็ไม่เป็นเช่นนั้น ฉันไม่เห็นอะไรเกี่ยวกับสิ่งนี้ในคำถามของคุณดังนั้นฉันจึงไม่ต้องกังวลกับการดำน้ำ คำตอบอื่น ๆ และ Wikipedia นั้นมีข้อมูลที่ดีมากมาย

นอกจากนี้ยังมีสิ่งต่างๆมากมายให้เรียนรู้เกี่ยวกับเทคโนโลยีเครือข่ายต่างๆที่สร้างขึ้นบน HTTP ที่คุณสามารถใช้ประโยชน์จากหากคุณใช้ API พักผ่อนอย่างแท้จริง ฉันจะเริ่มต้นด้วยการตรวจสอบ

เกี่ยวกับการใช้ส่วนขยายเพื่อกำหนดชนิดข้อมูล ฉันสังเกตเห็นว่า MailChimp API กำลังทำอยู่ แต่ฉันไม่คิดว่านี่เป็นความคิดที่ดี

GET /zzz/cars.json/1

GET /zzz/cars.xml/1

เสียงของฉันเป็นความคิดที่ดี แต่ฉันคิดว่าวิธีการ "เก่ากว่า" ดีกว่าโดยใช้ส่วนหัว HTTP

GET /xxx/cars/1
Accept: application/json

ส่วนหัว HTTP ยังดีกว่ามากสำหรับการสื่อสารข้ามข้อมูล (ถ้ามีใครต้องการ)

POST /zzz/cars
Content-Type: application/xml     <--- indicates we sent XML to server
Accept: application/json          <--- indicates we want get data back in JSON format  

ฉันพลาดอะไรไปรึเปล่า?

ใช่. ;-)

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

หมายเหตุ: ข้อ จำกัด ของอินเทอร์เฟซที่เหมือนกันมีความสำคัญหากคุณต้องการแยกลูกค้าออกจากบริการ มันคล้ายกับการกำหนดอินเทอร์เฟซสำหรับคลาสเพื่อแยกพวกเขาออกจากกัน Ofc ในส่วนนี้ชุดอินเตอร์เฟสประกอบด้วยมาตรฐานเช่นHTTP , ชนิด MIME , URI , RDF , ลิงก์ข้อมูลที่เชื่อมโยง , คำศัพท์ไฮดราฯลฯ

ความหมายที่ดีมีความสำคัญในการเขียนโปรแกรม

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

ทำไม?

เพราะคุณรู้ว่า GET จะดึงข้อมูลจาก API ของคุณ คุณรู้ว่า POST จะเพิ่มข้อมูลใหม่ให้กับระบบของคุณ คุณรู้ว่า PUT จะทำการอัปเดต DELETE จะลบแถว ฯลฯ ฯลฯ

ปกติฉันจัดโครงสร้าง RESTFUL Web Services ของฉันเพื่อให้ฉันมีฟังก์ชันการเรียกกลับชื่อในสิ่งเดียวกับวิธีการ

ฉันใช้ PHP ดังนั้นฉันจึงใช้ function_exists (ฉันคิดว่ามันเรียกว่า) หากฟังก์ชั่นไม่มีอยู่ฉันจะโยน 405 (ไม่อนุญาต)

Bill Venners:ในบล็อกโพสต์ของคุณชื่อ "Why REST Failed" คุณกล่าวว่าเราต้องการคำกริยา HTTP ทั้งสี่คำ ได้แก่ GET, POST, PUT และ DELETE และคร่ำครวญว่าผู้ขายเบราว์เซอร์เพียง GET และ POST คำกริยาทำไม GET และ POST ไม่พอ?

Elliotte Rusty Harold:มีสี่วิธีพื้นฐานใน HTTP: GET, POST, PUT และ DELETE GET ใช้เวลาส่วนใหญ่ มันใช้สำหรับทุกสิ่งที่ปลอดภัยที่ไม่ก่อให้เกิดผลข้างเคียงใด ๆ GET สามารถทำบุ๊กมาร์กแคชเชื่อมโยงผ่านพร็อกซีเซิร์ฟเวอร์ มันคือการดำเนินการที่มีประสิทธิภาพมากการดำเนินการที่มีประโยชน์มาก

POST by contrast อาจเป็นการดำเนินการที่ทรงพลังที่สุด มันสามารถทำอะไรก็ได้ ไม่มีข้อ จำกัด เกี่ยวกับสิ่งที่สามารถเกิดขึ้นได้และเป็นผลให้คุณต้องระวังให้มาก คุณไม่ได้คั่นหน้ามัน คุณไม่แคช คุณไม่ดึงข้อมูลล่วงหน้า คุณไม่ได้ทำอะไรกับโพสต์โดยไม่ถามผู้ใช้ คุณต้องการทำสิ่งนี้หรือไม่? หากผู้ใช้กดปุ่มคุณสามารถโพสต์เนื้อหาบางส่วน แต่คุณจะไม่ดูปุ่มทั้งหมดในหน้าและเริ่มต้นการกดแบบสุ่ม ในทางตรงกันข้ามเบราว์เซอร์อาจดูลิงก์ทั้งหมดในหน้านั้นและดึงข้อมูลล่วงหน้าหรือดึงข้อมูลที่พวกเขาคิดว่าน่าจะมีการติดตามต่อไป และในความเป็นจริงแล้วเบราว์เซอร์และส่วนขยาย Firefox และเครื่องมืออื่น ๆ ได้พยายามทำเช่นนั้นในจุดหนึ่ง

PUT และ DELETE อยู่ตรงกลางระหว่าง GET และ POST ความแตกต่างระหว่าง PUT หรือ DELETE และ POST คือ PUT และ DELETE เป็น * idempotent ในขณะที่ POST ไม่ใช่ PUT และ DELETE สามารถทำซ้ำได้หากจำเป็น สมมติว่าคุณกำลังพยายามอัปโหลดหน้าใหม่ไปยังเว็บไซต์ สมมติว่าคุณต้องการสร้างหน้าใหม่ที่ http://www.example.com/foo.htmlดังนั้นคุณพิมพ์เนื้อหาของคุณและคุณใส่มันที่ URL นั้น เซิร์ฟเวอร์สร้างหน้านั้นที่ URL ที่คุณระบุ ทีนี้สมมติว่าเหตุผลบางอย่างที่การเชื่อมต่อเครือข่ายของคุณล่ม คุณไม่แน่ใจว่าคำขอผ่านหรือไม่ บางทีเครือข่ายอาจช้า อาจมีปัญหาพร็อกซีเซิร์ฟเวอร์ ดังนั้นจึงเป็นเรื่องที่ดีที่จะลองอีกครั้งหรืออีกครั้ง - หลาย ๆ ครั้งตามที่คุณต้องการ เนื่องจากการวางเอกสารเดียวกันใน URL เดียวกันสิบครั้งจะไม่แตกต่างจากการใส่ครั้งเดียว เช่นเดียวกับ DELETE คุณสามารถลบบางสิ่งได้สิบครั้งและนั่นก็เหมือนกับการลบครั้งเดียว

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

กรุณาเยี่ยมชม URL สำหรับรายละเอียดเพิ่มเติม http://www.artima.com/lejava/articles/why_put_and_delete.html

ปรับปรุง:

วิธีการ Idempotent idempotent HTTP เป็นวิธี HTTP ที่สามารถเรียกได้หลายครั้งโดยไม่มีผลลัพธ์ที่แตกต่างกัน มันจะไม่สำคัญว่าวิธีการนั้นถูกเรียกเพียงครั้งเดียวหรือมากกว่าสิบครั้ง ผลลัพธ์ควรเหมือนกัน อีกครั้งสิ่งนี้ใช้ได้กับผลลัพธ์ไม่ใช่ตัวทรัพยากรเอง ยังคงสามารถจัดการได้ (เช่นการอัพเดตเวลาประทับหากข้อมูลนี้ไม่ได้ถูกแชร์ในการแสดงทรัพยากร (ปัจจุบัน)

ลองพิจารณาตัวอย่างต่อไปนี้:

a = 4;

A ++;

ตัวอย่างแรกคือ idempotent: ไม่ว่าเราจะเรียกใช้คำสั่งนี้กี่ครั้งก็ตาม a จะเท่ากับ 4 ตัวอย่างที่สองไม่ใช่ idempotent การดำเนินการนี้ 10 ครั้งจะส่งผลให้ผลลัพธ์ที่แตกต่างเช่นเมื่อทำงาน 5 ครั้ง เนื่องจากทั้งสองตัวอย่างกำลังเปลี่ยนค่าของ a ดังนั้นทั้งคู่จึงเป็นวิธีที่ไม่ปลอดภัย

โดยทั่วไป REST คือ ( wiki ):

1. สถาปัตยกรรมไคลเอนต์ - เซิร์ฟเวอร์
2. การเป็นไร้สัญชาติ
3. cacheability
4. ระบบเลเยอร์
5. รหัสตามต้องการ (ไม่บังคับ)
6. ชุดอินเตอร์เฟส

REST ไม่ใช่โปรโตคอล แต่เป็นหลักการ ยูริที่แตกต่างกันและวิธีการ - ใครบางคนเรียกว่าปฏิบัติที่ดีที่สุด