ใช้ API ถ้าฉันแก้ไขส่วนหัวของประเภทเนื้อหาที่จะทำลายสิ่งต่าง ๆ สำหรับลูกค้า?


14

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

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

อาจขึ้นอยู่กับว่ามีการใช้ไคลเอนต์ HTTP ประเภทใดดังนั้นฉันจึงดูตัวแทนผู้ใช้ คำตอบ: มีหลายสิ่งหลายอย่าง! นี่คือบางส่วนของคนชั้นนำ:

"okhttp / 3.2.0", "python-ร้องขอ / 2.10.0", "Ruby", "python-ร้องขอ / 2.7.0", "Mozilla / 5.0", "Java / 1.8.0_91", "python-ร้องขอ /2.4.3 "," okhttp / 3.3.0 "," Lucee "," Dalvik / 2.1.0 "," Google-HTTP-Java-Client / 1.21.0 "," PHP_appname "," NativeHost "," Java /1.7.0_67 "," Apache-HttpClient / UNAVAILABLE "," Dalvik / 1.6.0 "," Web-sniffer / 1.1.0 "," unirest-objc / 1.1 "

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

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


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

5
ข้อบังคับ xkcd: xkcd.com/1172
njzk2

คุณไม่ได้กำหนดเวอร์ชัน API ใช่หรือไม่
Michael Hampton

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

คำตอบ:


30

มันจะเลวร้ายขนาดไหนสำหรับลูกค้าปัจจุบันของเรา?

มันอาจจะจมเรือประจัญบานของพวกเขาได้อย่างสมบูรณ์หากพวกเขาเขียนโค้ดที่ต้องอาศัยประเภทเนื้อหาที่ไม่ถูกต้อง

ฉันจะไม่คาดหวังว่าไลบรารีจะโยนข้อผิดพลาด แต่ฉันคาดว่าในบางกรณีไลบรารีที่เข้มงวดจะมีพฤติกรรมของพวกเขาแทนที่การจัดการชนิด MIME ที่ไม่ถูกต้อง

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


6
+1 แล้วสำหรับอติพจน์ที่ดี
HBruijn

4
บ่อยครั้งที่คุณไม่มีทางเลือก ลูกค้าที่ได้รับ "อัปเดตหรือออกจาก" คำขาดอาจตัดสินใจหลังดีในหลักการไม่ดีในทางปฏิบัติ เวอร์ชันเก่าสามารถยกเลิกได้เมื่อเวลาผ่านไป
อัลซี

3
+1 หรือขอเวอร์ชันแม้ว่าคุณอาจต้องการตรวจสอบen.wikipedia.org/wiki/Software_versioningสำหรับข้อมูลเพิ่มเติม
SBoss

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

1
ดูเหมือนว่าจะเป็นจุดที่ดีมากโดยทาง: "ฉันคาดหวังว่าในบางกรณีห้องสมุดที่เข้มงวดมีพฤติกรรมของพวกเขาถูกแทนที่เพื่อจัดการกับประเภท mime ที่ไม่ถูกต้อง"ลางสังหรณ์ของฉัน (เป็นคำตอบของคำถามทั้งหมด) คือลูกค้าส่วนใหญ่ ห้องสมุดจะดีกับสิ่งนี้ แต่นี่เป็นข้อกังวล ลูกค้าบางรายอาจทำงานอย่างมืออาชีพในเรื่องนี้และการแลกเปลี่ยนก็จะทำลายมันสำหรับพวกเขา ฉันสงสัยว่ามันเกิดขึ้นมากแค่ไหน
แฮร์รี่วู้ด

11

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

ไม่ทุกไลบรารี่ไคลเอนต์ HTTP ที่ฉันคุ้นเคยจะละเว้นส่วนหัวของชนิดเนื้อหายกเว้นว่าโปรแกรมเมอร์จะอ่านส่วนหัวนั้นโดยเฉพาะและทำบางสิ่งกับมัน ฉันสามารถจินตนาการห้องสมุดที่มี content-type: application / json ทำให้ json parser มีส่วนร่วมโดยอัตโนมัติ แต่ฉันไม่ทราบว่ามีกรณีใดเกิดขึ้นจริง

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

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


คำตอบของฉันมีตัวอย่างที่ว่าจะเกิดขึ้นจริง
ต้มตุ๋น

หากคุณใช้ jQuery $.ajaxและไม่ได้ระบุdataType:ตัวเลือกจะมีประเภทตอบกลับจากContent-typeส่วนหัว ดังนั้นหากเป็นapplication/jsonเช่นนั้นระบบจะทำการวิเคราะห์คำโดยอัตโนมัติก่อนส่งต่อไปยังผู้โทร
Barmar

6

ยากเกินกว่าจะบอกได้โดยไม่ต้องลงชื่อออกจากลูกค้าของคุณ ฉันขอแนะนำให้ใช้หนึ่งในสองวิธีต่อไปนี้เพื่ออัปเกรด API ของคุณเป็น v.Next

  1. ขยาย API ที่มีอยู่ เพิ่มสตริงการสืบค้นหรือตัวแปรอื่น ๆ ให้กับ API ของคุณซึ่งหมายถึงการใช้ v.Next สำหรับคำขอทั้งหมดที่ใช้ตัวแปรนั้นให้ใช้ประเภทเนื้อหาที่อัปเดต
  2. ใช้งาน Staging หรือ Pre-Production ของ API ของคุณควบคู่ไปกับ API ปัจจุบันของคุณ ควรใกล้เคียงกับการผลิต แม้ใช้แบ็คเอนด์เดียวกัน แม้ว่าอันนี้จะมีการเปลี่ยนแปลงที่เสนอสำหรับ v.Next

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

ตรวจสอบให้แน่ใจว่าคุณมีหน้าเฉพาะที่ให้รายละเอียดการเปลี่ยนแปลงที่ทำกับ v.Next สิ่งนี้ควรรวมอยู่ในการสื่อสารที่ส่งถึงลูกค้าของคุณ หากคุณพูดคุยเกี่ยวกับการแก้ไขใด ๆ กับลูกค้าที่มีอยู่รวมถึงการแก้ไขในหน้านี้

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

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


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

5

นี่คือตัวอย่างของไลบรารี่ (คำสั่งเดียว) ที่จะทำให้:

cmdlet Invoke-RestMethodทำหน้าที่แตกต่างกันกับ JSON หากผลลัพธ์ของคำขอคือ JSON, XML หรือ ATOM / RSS (และฉันคิดว่ามันขึ้นอยู่กับส่วนหัว) มันจะแยกวิเคราะห์ / deserializes และส่งกลับวัตถุพื้นเมืองมิฉะนั้นจะส่งคืนข้อมูลดิบ

ดังนั้นรหัสที่มีอยู่จะถูกเขียนขึ้นเพื่อจัดการกับสตริง (อาจส่งผ่านไปยังConvertFrom-Json) และการเริ่มต้นทั้งหมดจะล้มเหลวทันที


blogs.technet.microsoft.com/heyscriptingguy/2013/10/21/…ยืนยันทฤษฎีที่ว่านี้มีลักษณะที่ส่วนหัว
Winston Ewert

-2

ฉันสังเกตเห็นสองผล:

  1. บางไลบรารีไคลเอ็นต์จะไม่ประมวลผลการตอบสนองอย่างถูกต้อง ตัวอย่างเช่นการตอบสนองกลับสตริงแทน json หรืออาร์เรย์
  2. การบีบอัดจะไม่นำไปใช้เสมอ

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