ตกลงเพื่อส่งคืน HTML จาก JSON API หรือไม่

ในโครงการปัจจุบันของฉันฉันรับผิดชอบการใช้งานบริการที่เกี่ยวข้องกับการใช้ RESTful APIs ที่สร้างขึ้นใหม่ซึ่งบันทึกไว้ว่ารองรับ JSON เท่านั้น

ลูกค้าทำการร้องขออย่างต่อเนื่องโดยมีส่วนหัวการยอมรับของ 'application / json' และประเภทเนื้อหาของ 'application / json' อย่างไรก็ตามปลายทางบางจุดส่งการตอบกลับด้วย HTML ชนิดเนื้อหาหรือแม้แต่เนื้อหา HTML สำหรับฉันนี่เป็นแนวทางที่ผิดอย่างชัดเจนและไม่สามารถพิสูจน์ได้

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

นี่เป็นจุดสำคัญของความยุ่งยาก ฉันไม่พบการอ้างอิงจำนวนมากเพื่อสำรองอาร์กิวเมนต์ของฉันฉันคิดว่านี่เป็นเพราะประเด็นนั้นเป็นที่สงสัยเนื่องจากมันชัดเจนมาก

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

เมื่อคุณกำลังส่งacceptส่วนหัวที่ร้องขอประเภทสื่อเฉพาะเซิร์ฟเวอร์ไม่ควรส่งสิ่งอื่นกลับมาและแน่นอนที่สุดไม่ใช่รหัสสถานะ 200 OK

จาก Restpatterns.org :

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

(เหมืองเน้น)

Restpatterns.org ใช้สิ่งนี้จากมาตรฐาน HTTP จริง: นิยามฟิลด์ส่วนหัว - ยอมรับ

ในระยะสั้น: คุณไม่ได้อวดรู้ บริการไม่ได้ปฏิบัติตามมาตรฐาน HTTP หากพวกเขาจะกลับ HTML เมื่อส่วนหัวยอมรับโดยเฉพาะบอกให้พวกเขากลับมาapplication/jsonและไม่มีอะไรอื่น

คุณหมายถึงอะไรโดย "RESTful JSON API" - ฉันคิดว่าปัญหาแรกที่นี่คือคุณกำลังมั่วสุมคิด (หรืออาจเป็นใครบางคนระหว่างคุณและคู่หูด้านเทคนิคของคุณที่ "ซัพพลายเออร์" ของคุณ)

RESTful API (ไม่ว่าคุณจะพูดไม่ได้พักที่ระดับ 1 หรือระดับ 3 หรือสูงกว่า cf http://martinfowler.com/articles/richardsonMaturityModel.html ) เป็นเรื่องเกี่ยวกับวิธีที่คุณโต้ตอบกับ API ที่ไม่เกี่ยวกับ รูปแบบของเนื้อหาที่ส่งหรือรับจาก มันไม่ได้เกี่ยวกับโปรโตคอลหรือกลไกการขนส่ง ...

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

ดี API ทำงานผ่าน HTTP (มันมีเหตุผลที่จะคิดว่าในบริบทที่คุณกำลังพูดคุยเกี่ยวกับ API โล่งผ่าน HTTP) จะช่วยให้คุณร้องขอเนื้อหาในความหลากหลายของรูปแบบและรูปแบบเหล่านั้นสามารถ (และอาจจะควร) รวม HTML เช่นเดียวกับ JSON และ XML ทำไม? มันจะทำให้การเรียนรู้ API ง่ายขึ้นมากโดยทางความคิดมันมี UX เบราว์เซอร์ที่ทำงานได้ทันทีไม่ว่าจะด้วยวัตถุประสงค์อะไร ...

คำถามที่น่าสนใจจะเกิดขึ้นถ้า API ของฉันซึ่งรองรับรูปแบบเนื้อหาหลากหลายถูกเรียกโดยไม่บอกว่ารูปแบบที่ลูกค้าคาดหวังรูปแบบใดที่ควรกลับมา ... สิ่งนี้มีแนวโน้มที่จะเป็นข้อโต้แย้งทางศาสนา แต่ HTML ให้ตัวเลือกแก่ผู้ให้บริการในการรวมข้อมูลที่เป็นประโยชน์ (เช่น "อย่าลืมตั้งค่าหัวข้อการยอมรับเนื้อหา")

เพื่อที่จะตอบคำถามเกี่ยวกับ API นั้นเป็นสิ่งที่สงบและอีกอย่างหนึ่งที่สนับสนุน json จะต้องสามารถส่งคืน HTML ได้หากเป็นเนื้อหาที่ร้องขอ

ลูกค้าทำการร้องขออย่างต่อเนื่องโดยมีส่วนหัวการยอมรับของ 'application / json' และประเภทเนื้อหาของ 'application / json'

ใช่นี่เป็นสิ่งที่ต้องทำ แต่ไม่ได้หมายความว่าผู้ขายจะใส่ใจ ในขณะที่ฉันเข้าใจความคับข้องใจของคุณอย่างสิ้นเชิงเพราะฉันคิดว่าบริการ JSON ควรตอบสนองต่อ JSON เสมอ แต่มีหลายตัวอย่างที่ไม่ได้เป็นเช่นนั้น

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

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

คำถามคือฉันไม่มีอะไร?

ส่วนหัวของคำขอไม่มีความหมายอะไรนอกจากว่าพวกเขาจะถูกขัดจังหวะอย่างถูกต้องในส่วนอื่น ๆ ฉันรู้ว่าถ้าฉันพัฒนาเว็บ API โดยใช้ PHP งั้นก็ตกนรกด้วยส่วนหัวคำขอ ฉันสามารถตอบสนองกับสิ่งที่ฉันต้องการ ในขณะที่บริการที่กำหนดค่าใน IIS ด้วย C # ให้การจัดการส่วนหัวคำขอได้ง่ายขึ้นประเภทและการจัดการประเภทการตอบสนอง มีหลายอย่างที่เกี่ยวข้องกับเครื่องมือที่ผู้ขายใช้ในการสร้าง API

ฉันเป็นคนที่กระตือรือร้นเกี่ยวกับเรื่องนี้หรือไม่

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

มันเป็นปัญหาเพราะผู้ขายได้สร้าง "งานมากขึ้น" เพื่อให้งานของคุณเสร็จสมบูรณ์ ใคร ๆ ก็คงต้องผิดหวังกับสิ่งนั้น ฉันรู้ว่าฉันจะเป็น

ตกลงหรือไม่ที่จะมี JSON API ที่ไม่มีประเภทแอปพลิเคชัน / json ในสถานการณ์นี้

อย่างแน่นอน แต่มันไม่ใช่วิธีปฏิบัติที่ดี

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

นิยามฟิลด์ส่วนหัว

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

เป็นไปได้ที่ลูกค้าจะร้องขอภาพimage/jpegแต่เซิร์ฟเวอร์ตอบกลับด้วยtext/htmlและรหัสสถานะ404หากไม่พบภาพ เซิร์ฟเวอร์สามารถตอบกลับอย่างไม่ถูกต้อง มีเว็บไซต์ Wordpress มากมายที่ตอบสนองtext/htmlและรหัสสถานะ200สำหรับไฟล์ที่ไม่พบหน้าเว็บ

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

การอ้างอิงจะได้รับการชื่นชม คุณจะแก้ไขสถานการณ์นี้จากมุมมองทางการค้าได้อย่างไร

ฉันพบปัญหานี้ในบางโครงการ คุณpostJSON data ไปยังเซิร์ฟเวอร์และให้การตอบกลับ JSON หรือ HTML

ไม่ใช่เรื่องใหญ่ที่จะรู้ว่าประเภทใดที่ตอบสนอง หากอักขระตัวแรกคือ{หรือ[คุณสามารถใช้ JSON ถ้าเป็นเช่นนั้น<คุณสามารถถือว่า HTML นั่นเป็นวิธีที่ฉันจัดการในอดีต บางครั้งโปรแกรมเมอร์ที่เขียน API รู้แจ็คเกี่ยวกับส่วนหัว HTTP ทั้งหมด ทุกอย่างกลับมาเป็นtext/htmlคำตอบ หากคุณโชคดีพวกเขามี Apache กำหนดค่าให้เริ่มต้นtext/plainซึ่งบางครั้งสามารถช่วยได้

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