ฉันรู้สึกเศร้าเล็กน้อยที่เห็นว่าหลังจากผ่านไปกว่า 10 ปีแล้วไม่มีคำตอบว่าจริง ๆ แล้วสิ่งที่ได้รับการร้องขอใน OP สามารถออกแบบในสถาปัตยกรรม REST ได้ดังนั้นฉันจึงรู้สึกว่าต้องทำเช่นนี้ในตอนนี้
สิ่งแรกสิ่งที่เหลือคืออะไร! REST ย่อหรือ ReST ย่อมาจาก "Representational State Transfer" และกำหนดการแลกเปลี่ยนสถานะของทรัพยากรในรูปแบบการแสดงที่แน่นอน รูปแบบการนำเสนอเป็นไปตามประเภทของสื่อที่เจรจาต่อรอง ในกรณีของapplication/htmlรูปแบบการแสดงอาจเป็นสตรีมของเนื้อหาข้อความที่จัดรูปแบบ HTML ซึ่งแสดงผลในเบราว์เซอร์อาจหลังจากใช้การจัดรูปแบบสไตล์ชีทบางอย่างเพื่อจัดวางองค์ประกอบบางอย่างในตำแหน่งที่แน่นอน
REST เป็นหลักการทั่วไปของเว็บที่เรียกดูได้ที่เราทุกคนรู้แม้ว่าจะกำหนดเป้าหมายไปที่แอปพลิเคชันทุกประเภทและไม่เพียงเบราว์เซอร์ ดังนั้นโดยการออกแบบแนวคิดเดียวกันที่นำไปใช้กับเว็บยังใช้กับสถาปัตยกรรมส่วนที่เหลือ คำถามเช่นวิธีการบรรลุบางสิ่งบางอย่างด้วยวิธี "สงบ" แก้ไขรอบการตอบคำถามวิธีการบรรลุบางสิ่งบางอย่างบนเว็บเพจแล้วนำแนวคิดเดียวกันไปใช้กับเลเยอร์แอปพลิเคชัน
เครื่องคิดเลขที่ใช้เว็บมักจะเริ่มต้นด้วย "หน้า" บางอย่างที่ช่วยให้คุณป้อนค่าบางอย่างเพื่อคำนวณก่อนที่จะส่งข้อมูลที่ป้อนไปยังเซิร์ฟเวอร์ ใน HTML นี้มักจะทำได้ผ่าน<form>องค์ประกอบHTML ที่สอนลูกค้าเกี่ยวกับพารามิเตอร์ที่มีให้ตั้งตำแหน่งเป้าหมายที่จะส่งคำขอไปยังเช่นเดียวกับรูปแบบการเป็นตัวแทนที่จะใช้เมื่อส่งข้อมูลอินพุต นั่นคือสามารถมีลักษณะเช่นนี้:
<html>
<head>
...
</head>
<body>
<form action="/../someResource" method="post" enctype="application/x-www-form-urlencoded">
<label for="firstNumber">First number:</label>
<input type="number" id="firstNumber" name="firstNumber"/>
<label for="secondNumber">Second number:</label>
<input type="number" id="secondNumber" name="secondNumber"/>
<input type="submit" value="Add numbers"/>
</form>
</body>
</html>
ตัวอย่างข้างต้นกล่าวคือมีช่องป้อนข้อมูลสองช่องที่ผู้ใช้กรอกข้อมูลหรือออโตมาตาอื่น ๆ และเมื่อเรียกใช้งานองค์ประกอบส่งข้อมูลเข้าเบราว์เซอร์จะดูแลการจัดรูปแบบข้อมูลอินพุตในapplication/x-www-form-urlencodedรูปแบบการนำเสนอที่ถูกส่ง ไปยังตำแหน่งเป้าหมายที่กล่าวถึงผ่านวิธีการร้องขอ HTTP ที่ระบุPOSTในกรณีนี้ หากเราเข้า1สู่ช่องfirstNumberป้อนข้อมูลและ2ลงในช่องsecondNumberป้อนข้อมูลเบราว์เซอร์จะสร้างการแสดงfirstNumber=1&secondNumber=2และส่งสิ่งนี้เป็นส่วนของเนื้อหาของคำขอจริงไปยังทรัพยากรเป้าหมาย
คำขอ HTTP ดิบที่ออกให้กับเซิร์ฟเวอร์อาจมีลักษณะเช่นนี้:
POST /../someResource
Host: www.acme.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 28
Accept: application/html
firstNumber=1&secondNumber=2
เซิร์ฟเวอร์อาจทำการคำนวณและตอบกลับด้วยหน้า HTML เพิ่มเติมที่มีผลลัพธ์ของการคำนวณตามคำขอที่ระบุว่าลูกค้าเข้าใจรูปแบบนี้
ดังที่ Breton ชี้ให้เห็นแล้วไม่มีสิ่งใดเป็น URL "RESTful" หรือ URI URI / URL เป็นประเภทของตนเองและไม่ควรสื่อความหมายใด ๆ กับลูกค้า / ผู้ใช้ ในตัวอย่างเครื่องคิดเลขด้านบนผู้ใช้ไม่สนใจว่าจะส่งข้อมูลไปที่ใดและสนใจเพียงว่าเมื่อทริกเกอร์ช่องป้อนข้อมูลการส่งคำขอจะถูกส่งไป ข้อมูลที่จำเป็นทั้งหมดที่จำเป็นสำหรับการทำงานควรได้รับจากเซิร์ฟเวอร์แล้ว
เบราว์เซอร์อาจไม่ทราบว่าคำขอนั้นป้อนเครื่องคิดเลขด้วยพารามิเตอร์ป้อนเข้าจริง ๆ ก็อาจเป็นรูปแบบคำสั่งบางชนิดที่ส่งกลับการแสดงแบบฟอร์มถัดไปเพื่อดำเนินการสั่งซื้อต่อไปหรือบางประเภทที่แตกต่างกันโดยสิ้นเชิง ทรัพยากร. มันทำสิ่งที่ HTML spec ต้องการในกรณีเช่นนี้และไม่สนใจว่าเซิร์ฟเวอร์กำลังทำอะไรอยู่ แนวคิดนี้ทำให้เบราว์เซอร์ใช้รูปแบบการนำเสนอแบบเดียวกันเพื่อทำสิ่งต่าง ๆ เช่นการสั่งซื้อบางอย่างจากร้านค้าออนไลน์ที่คุณต้องการสนทนากับเพื่อนที่ดีที่สุดของคุณลงชื่อเข้าใช้บัญชีออนไลน์และอื่น ๆ
ความสามารถในการจ่ายขององค์ประกอบบางอย่างเช่นในกรณีที่ฟิลด์ป้อนข้อมูลที่มักจะแสดงผลเป็นปุ่มกำหนดสิ่งที่คุณควรทำกับมัน ในกรณีของปุ่มหรือลิงค์มันบอกให้คุณคลิก องค์ประกอบอื่น ๆ อาจสื่อถึงการจ่ายที่แตกต่างกัน ความสามารถในการจ่ายเงินดังกล่าวยังสามารถแสดงผ่านความสัมพันธ์ของลิงก์เช่นเดียวกับpreloadลิงก์ที่มีคำอธิบายประกอบที่โดยทั่วไปบอกลูกค้าว่าสามารถโหลดเนื้อหาของทรัพยากรที่เชื่อมโยงในพื้นหลังได้แล้วเนื่องจากผู้ใช้มักจะคว้าเนื้อหานี้ต่อไป ความสัมพันธ์เชื่อมโยงดังกล่าวควรของหลักสูตรได้มาตรฐานหรือตามกลไกส่วนขยายสำหรับความสัมพันธ์ประเภทตามที่กำหนดโดยเว็บเชื่อมโยง
นี่เป็นแนวคิดพื้นฐานที่ใช้บนเว็บและควรใช้ในสถาปัตยกรรม REST อ้างอิงจาก "ลุงบ็อบ" โรเบิร์ตซีมาร์ตินซีสถาปัตยกรรมเกี่ยวกับความตั้งใจและความตั้งใจที่อยู่เบื้องหลังสถาปัตยกรรมส่วนที่เหลือคือการแยกลูกค้าออกจากเซิร์ฟเวอร์เพื่อให้เซิร์ฟเวอร์สามารถพัฒนาได้อย่างอิสระในอนาคตโดยไม่ต้องกลัวพวกเขาจะทำลายลูกค้า น่าเสียดายที่ต้องมีวินัยมากเพราะเป็นเรื่องง่ายที่จะแนะนำการมีเพศสัมพันธ์หรือเพิ่มโซลูชั่นการแก้ไขอย่างรวดเร็วเพื่อให้งานเสร็จและไปต่อ ดังที่ Jim Webber ชี้ให้เห็นในสถาปัตยกรรม REST คุณในฐานะผู้ให้บริการควรพยายามออกแบบโปรโตคอลแอปพลิเคชันโดเมนที่คล้ายกับเกมคอมพิวเตอร์ที่ใช้ข้อความในยุค 70ที่ลูกค้าจะทำตามจนกว่าจะสิ้นสุดกระบวนการ
สิ่งที่เรียกว่า "REST" APIs ที่น่าเสียดายในความเป็นจริงคือทุกสิ่ง แต่นั่น คุณเห็นการแลกเปลี่ยนข้อมูลส่วนใหญ่ที่ใช้ JSON ซึ่งระบุไว้ในเอกสารภายนอกเฉพาะ API ซึ่งยากที่จะผสานรวมแบบทันที รูปแบบที่คำขอต้องมีลักษณะเป็นฮาร์ดโค้ดในเอกสารภายนอกซึ่งนำไปสู่การดำเนินการแปล URIs จำนวนมากเพื่อส่งกลับ typs ที่กำหนดไว้ล่วงหน้าแทนที่จะใช้รูปแบบการแสดงทั่วไปที่มีการเจรจาล่วงหน้า สิ่งนี้ป้องกันไม่ให้เซิร์ฟเวอร์เปลี่ยนแปลงเนื่องจากลูกค้าคาดหวังว่าจะได้รับรูปแบบข้อมูลบางอย่าง (หมายเหตุไม่ใช่รูปแบบการแสดง!) สำหรับ URIs ที่กำหนดไว้ล่วงหน้า การแลกเปลี่ยนรูปแบบข้อมูลที่กำหนดเองนี้ยังป้องกันไม่ให้ลูกค้าโต้ตอบกับ API อื่น ๆ เนื่องจาก "รูปแบบข้อมูล" มักจะไหลไปยัง API เฉพาะ เรารู้แนวคิดนี้จากอดีตจากเทคโนโลยี RPC เช่น Corba, RMI หรือ SOAP ซึ่งเราประณามอย่างชั่วร้ายแม้ว่า Peppol จะย้ายไปที่มันอีกครั้งโดยแทนที่ AS2 ด้วย AS4 เป็นโปรโตคอลการโอนเริ่มต้นเมื่อเร็ว ๆ นี้
ในส่วนที่เกี่ยวกับคำถามจริงที่ถามการส่งข้อมูลเป็นไฟล์ csv ไม่แตกต่างจากการใช้การapplication/x-www-form-urlencodedแสดงหรือสิ่งที่คล้ายกัน จิมเวบเบอร์ทำให้มันชัดเจนว่าหลังจากที่ทุกHTTP เป็นเพียงโปรโตคอลการขนส่งที่มีประสิทธิภาพการประยุกต์ใช้การโอนเอกสารผ่านเว็บที่ ไคลเอ็นต์และเซิร์ฟเวอร์อย่างน้อยควรทั้งการสนับสนุนtext/csvตามที่กำหนดในRFC 7111 ไฟล์ CSV นี้สามารถสร้างขึ้นได้เนื่องจากการประมวลผลประเภทสื่อที่กำหนดองค์ประกอบของรูปแบบองค์ประกอบเป้าหมายหรือแอตทริบิวต์เพื่อส่งคำขอไปยังรวมถึงวิธีการ HTTP เพื่อทำการอัปโหลดการกำหนดค่า
มีสองประเภทสื่อที่สนับสนุนรูปแบบเช่นเป็นHTML , รูปแบบ HAL , halform , ไอออนหรือไฮดรา ผมอยู่ แต่ไม่ทราบชนิดของสื่อที่จะสามารถเข้ารหัสข้อมูลที่ป้อนเข้าไปtext/csvโดยตรงด้วยเหตุหนึ่งต้องอาจจะกำหนดและลงทะเบียนกับรีจิสทรีชนิดของสื่อ IANA ของ
การอัปโหลดและดาวน์โหลดชุดพารามิเตอร์ที่สมบูรณ์ไม่ควรเป็นปัญหาที่ฉันเดา ตามที่กล่าวไว้ก่อนหน้านี้ URI เป้าหมายไม่เกี่ยวข้องเนื่องจากลูกค้าจะใช้ URI เพื่อดึงเนื้อหาใหม่เพื่อดำเนินการ การกรองตามวันธุรกิจไม่ควรเป็นเรื่องยาก ที่นี่เซิร์ฟเวอร์ควรเป็นลูกค้าที่มีความเป็นไปได้ทั้งหมดที่ลูกค้าสามารถเลือกได้ ในช่วงไม่กี่ปีที่ผ่านมา GraphQL และ RestQL ได้รับการพัฒนาซึ่งแนะนำ SQL เช่นภาษาที่สามารถกำหนดเป้าหมายได้ที่จุดปลายที่แน่นอนเพื่อรับการตอบกลับที่ผ่านการกรอง อย่างไรก็ตามในความรู้สึกที่แท้จริงนี้เป็นการละเมิดแนวคิดเบื้องหลัง REST ในฐานะก) GraphQL คือใช้จุดปลายเดียวซึ่งป้องกันการใช้แคชอย่างเหมาะสมและข) ต้องการความรู้เกี่ยวกับเขตข้อมูลที่มีอยู่ซึ่งอาจนำไปสู่การมีเพศสัมพันธ์ของลูกค้า เป็นโมเดลข้อมูลพื้นฐานของทรัพยากร
การเปิดใช้งานหรือปิดใช้งานพารามิเตอร์การกำหนดค่าบางอย่างเป็นเพียงเรื่องของการกระตุ้นให้เกิดการควบคุมสื่อหลายมิติที่ให้ค่าใช้จ่ายนี้ ในรูปแบบ HTML นี้อาจเป็นช่องทำเครื่องหมายง่ายหรือการเลือกหลายบรรทัดในรายการหรือประเภทนั้น ขึ้นอยู่กับแบบฟอร์มและวิธีการที่กำหนดว่าจะสามารถส่งการกำหนดค่าทั้งหมดผ่านPUTหรือฉลาดเกี่ยวกับการเปลี่ยนแปลงที่ทำและทำการอัปเดตบางส่วนผ่านPATCHเท่านั้น อันหลังจำเป็นต้องมีเครื่องคิดเลขของการเป็นตัวแทนการเปลี่ยนแปลงกับสิ่งที่อัปเดตแล้วและฟีดเซิร์ฟเวอร์ด้วยขั้นตอนที่จำเป็นเพื่อเปลี่ยนการนำเสนอปัจจุบันเป็นสิ่งที่ต้องการ ตามข้อกำหนดของ PATHต้องทำภายในธุรกรรมเพื่อให้ขั้นตอนทั้งหมดหรือไม่ใช้เลย
HTTP อนุญาตและสนับสนุนให้เซิร์ฟเวอร์ตรวจสอบคำขอที่ได้รับล่วงหน้าก่อนที่จะใช้การเปลี่ยนแปลง สำหรับPUTสถานะ spec:
เซิร์ฟเวอร์ต้นทางควรตรวจสอบว่าการเป็นตัวแทน PUT สอดคล้องกับข้อ จำกัด ใด ๆ ที่เซิร์ฟเวอร์มีสำหรับทรัพยากรเป้าหมายที่ไม่สามารถหรือจะไม่สามารถเปลี่ยนแปลงได้โดย PUT สิ่งนี้มีความสำคัญอย่างยิ่งเมื่อเซิร์ฟเวอร์ต้นทางใช้ข้อมูลการกำหนดค่าภายในที่เกี่ยวข้องกับ URI เพื่อตั้งค่าสำหรับการแสดงข้อมูลเมตาบนการตอบกลับของ GET เมื่อการแสดง PUT ไม่สอดคล้องกับทรัพยากรเป้าหมายเซิร์ฟเวอร์ต้นทางควรทำให้สอดคล้องกันโดยการเปลี่ยนการนำเสนอหรือเปลี่ยนการกำหนดค่าทรัพยากรหรือตอบสนองด้วยข้อความแสดงข้อผิดพลาดที่เหมาะสมที่มีข้อมูลเพียงพอที่จะอธิบายว่าทำไมการแสดงไม่เหมาะสม แนะนำให้ใช้รหัสสถานะ 409 (ขัดแย้ง) หรือ 415 (ประเภทสื่อที่ไม่สนับสนุน)
ตัวอย่างเช่นหากทรัพยากรเป้าหมายมีการกำหนดค่าให้มีประเภทเนื้อหาของ "text / html" เสมอและการแสดง PUT มีประเภทเนื้อหาของ "image / jpeg" เซิร์ฟเวอร์ต้นทางควรดำเนินการอย่างใดอย่างหนึ่งต่อไปนี้:
กำหนดค่าทรัพยากรเป้าหมายใหม่เพื่อสะท้อนประเภทสื่อใหม่
ข เปลี่ยนการนำเสนอ PUT เป็นรูปแบบที่สอดคล้องกับทรัพยากรก่อนบันทึกเป็นสถานะทรัพยากรใหม่ หรือ,
ค. ปฏิเสธคำขอด้วยการตอบกลับ 415 (ชนิดสื่อที่ไม่สนับสนุน) ซึ่งระบุว่าทรัพยากรเป้าหมายถูก จำกัด ที่ "text / html" ซึ่งอาจรวมถึงลิงก์ไปยังทรัพยากรอื่นที่อาจเป็นเป้าหมายที่เหมาะสมสำหรับการเป็นตัวแทนใหม่
HTTP ไม่ได้กำหนดอย่างชัดเจนว่าวิธี PUT มีผลต่อสถานะของเซิร์ฟเวอร์ต้นทางอย่างไรนอกเหนือจากสิ่งที่สามารถแสดงได้โดยเจตนาของคำขอตัวแทนผู้ใช้และความหมายของการตอบกลับของเซิร์ฟเวอร์ต้นทาง ...
ในการหาผลรวมการโพสต์นี้คุณควรใช้ชนิดสื่อบันทึกที่มีอยู่ซึ่งอนุญาตให้คุณสอนลูกค้าเกี่ยวกับพารามิเตอร์อินพุตที่จำเป็นหรือได้รับการสนับสนุนตำแหน่งเป้าหมายที่จะส่งคำขอไปยังการดำเนินการที่จะใช้ ต้องจัดรูปแบบคำขอหรือกำหนดคำขอของคุณเองที่คุณลงทะเบียนกับ IANA หลังอาจจำเป็นถ้าคุณต้องการแปลงอินพุตtext/csvจากนั้นอัปโหลดการแสดง CSV ไปยังเซิร์ฟเวอร์ การตรวจสอบควรเกิดขึ้นก่อนที่การเปลี่ยนแปลงจะถูกนำไปใช้กับทรัพยากร URI ที่เกิดขึ้นจริงไม่ควรเกี่ยวข้องกับลูกค้าอื่นนอกจากเพื่อพิจารณาว่าจะส่งคำขอไปที่ใดและผู้ให้บริการดำเนินการนั้นสามารถเลือกได้โดยอิสระ เมื่อทำตามขั้นตอนเหล่านี้คุณจะมีอิสระในการเปลี่ยนฝั่งเซิร์ฟเวอร์ของคุณได้ตลอดเวลาและลูกค้าจะไม่หยุดพักหากพวกเขาสนับสนุนประเภทสื่อที่ใช้แล้ว