สิ่งที่จะเรียก HTTP API ที่ไม่สงบ [ปิด]

คุณจะเรียก API ที่ใช้ HTTP ใช้ URI เพื่อตั้งชื่อทรัพยากรและกริยา HTTP (PUT, POST, DELETE, GET ... ) เพื่อจัดการทรัพยากรเหล่านั้นอย่างไร

ตามการร้องเรียนของ Roy Fieldingไม่ใช่การพักเนื่องจากไม่มีไฮเปอร์มีเดีย

ภายในทีมของฉันทุกคนเรียกมันว่า "REST API" ฉันเรียกมันว่า "REST-like" แต่มันไม่ได้อธิบายและความหมายของมันนั้นคลุมเครือ ฉันค่อนข้างสับสนเกี่ยวกับเรื่องนี้เนื่องจากมีความขัดแย้งอย่างมากเกี่ยวกับ REST ฉันไม่ต้องการมีส่วนร่วมในสงครามไฟ แต่เพียงใช้คำที่ถูกต้อง

เรียกว่าHTTP API

มันสอดคล้องกับมาตรฐาน HTTP และไม่มีสิ่งอื่นใดที่อยู่ด้านบน (เช่น SOAP)

มาตรฐาน HTTP กำหนดทรัพยากรคำกริยาส่วนหัวการเจรจาต่อรองเนื้อหา ฯลฯ

REST (REpresentational State Transfer) เป็นสถาปัตยกรรมที่มีข้อกำหนดที่เกิดขึ้นเพื่อให้สอดคล้องกับมาตรฐาน HTTP ที่มีอยู่ แต่ HTTP ทำงานได้ด้วยตัวเอง

จากประสบการณ์ของฉัน 90% ของ "REST HTTP API" ควรเรียกตัวเองว่า "แค่" HTTP API

อย่าละอายที่จะละทิ้งฉลาก REST เช่นเดียวกับ microservices และฐานข้อมูลที่ไม่เกี่ยวข้องคุณไม่จำเป็นต้องมี RESTful API Roy เริ่มต้นเพื่อสร้างสถาปัตยกรรมแอปพลิเคชั่นเครือข่ายที่ใช้งานได้ยาวนานที่สุดและใช้งานได้ยาวนานที่สุด เขาทำได้ดีมาก แต่ไม่ใช่ทุกสิ่งที่ต้องการความเข้ากันได้มากกว่า 40 ปี

Richardson Maturity Models เป็นแบบนี้

0. โพสต์ทุกที่ จุดปลายเดียว (สบู่)
1. โพสต์ทุกที่ จุดปลายหลายจุด (ทรัพยากร)
2. HTTP VERBS จุดปลายหลายจุด
3. กดไลค์ 2 และส่งคืนลิงก์ไปยังแหล่งข้อมูล (สงบ)

ดังนั้นตามแบบผมจะเรียกมันว่าเว็บเซอร์วิซที่สอดคล้องกับริชาร์ดสันระดับ 2หรืออะไรบางอย่างตามสาย

http://martinfowler.com/articles/richardsonMaturityModel.html

ไฮเปอร์มีเดียไม่เคยได้รับความนิยมจาก API ที่คล้ายกับ REST จนถึงตอนที่ API ใช้การนำทางไฮเปอร์มีเดียจริง ๆ คำว่า RESTful นั้นไม่เพียงพอที่จะแยกแยะมันออกจากเว็บ API "RESTful" อื่น ๆ REST ได้กลายเป็นคำที่จับได้ทั้งหมดหรือ API บนเว็บที่ใช้ทรัพยากรและชื่อใหม่อย่างHypermedia API  ได้รับการประกาศเกียรติคุณเพื่อมุ่งเน้นแนวคิดของสื่อสิ่งพิมพ์

ฉันไม่ต้องการที่จะสนับสนุนการใช้คำที่ไม่ถูกต้อง แต่ฉันคิดว่าการตีความที่ทันสมัยทั่วไปของ REST นั้นหมายถึงการใช้ URL ที่สม่ำเสมอและคำกริยา HTTP สำหรับคนส่วนใหญ่ มันไม่ถูกต้อง แต่ใครก็ตามที่รู้คำจำกัดความของ Fieldings ควรรู้ด้วยว่าคนอื่น ๆ ไม่ชอบ ในทางกลับกันใครก็ตามที่รู้ว่า REST โดยการสังเกตว่ามีการนำ API "RESTful" ที่มีอยู่ไปใช้อย่างไรจะไม่รู้ว่าคุณกำลังพูดถึงอะไรเมื่อคุณพูดถึงข้อ จำกัด ของ REST ที่รู้จักกันน้อยเช่น HATEOAS หรือรหัสตามต้องการ ฟีลดิงอาจไม่ชอบ แต่ฉันคิดว่ามันจะสายไปแล้วที่จะกลับไปสู่คำนิยามเดิม * ถ้าอย่างนั้นคุณก็ได้ยินว่ามีคนพูดถึง REST API ของเขาเป็นครั้งแรกคุณจะคิดทันทีว่ามันไม่มีไฮเปอร์มีเดียใช่ไหม?

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

_{* และถึงกำหนดส่งคำศัพท์ใหม่สำหรับ API ที่ไม่ใช่ hypermedia คล้ายกับ REST สำหรับเรื่องนั้น เราควรเรียกพวกเขาว่าอย่างไร? ... พักอีกไหม?}

มันเป็นอินเตอร์เฟซ CRUD (สร้างอ่านอัปเดตลบ) ผ่าน HTTP

ฉันไม่สามารถนึกถึงหน่วยงานใด ๆ ในการสำรองการยืนยันนี้ดังนั้นฉันหวังว่าคุณจะได้รับคำตอบที่ดีขึ้น

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

ในทีมของเราเราตั้งชื่อของเราในStateless APIขณะที่มันกำลังพัฒนาเพราะเรามี SOAP API แบบ Stateful และ Functional ที่เราได้รับการแทนที่ (Legacy API นั้นไม่เคยมีชื่อที่เห็นด้วยและมีความหมายเช่นกันดังนั้นเราจึงไม่ติดชื่อ )

ตอนนี้โครงการนี้มีเพียงหนึ่ง API the <project> APIก็เรียกว่าเพียงแค่ เมื่อในที่สุดเราก็เปลี่ยนมันใหม่ API the new <project> APIก็จะเป็นที่รู้จัก

การให้ชื่อภายในที่เป็นแฟนซีและมีความหมายนั้นแทบไม่มีความหมายจนกว่าคุณจะมี API จำนวนมากที่คุณต้องแยกความแตกต่างนี้จากส่วนที่เหลือ (ในกรณีนี้คุณควรเปลี่ยนชื่อคนอื่นด้วย)

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

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