คุณต้องการเชื่อมโยงแอพของคุณกับ Facebook เพื่อให้สร้างโพสต์โดยอัตโนมัติ หรือไปที่ Instagram เพื่อให้คุณสามารถโพสต์รูปภาพใหม่ด้วยแฮชแท็กบางรายการ
คุณยังสามารถรวมวิดีโอ YouTube ไว้ในเว็บไซต์ของคุณได้อีกด้วย อินเทอร์เฟซการเขียนโปรแกรมแอปพลิเคชันช่วยให้คุณทำงานเหล่านี้ทั้งหมดและอื่นๆ (API)
แอปพลิเคชันต่างๆ สามารถ "พูด" ซึ่งกันและกันในลักษณะที่ปลอดภัยและเป็นมาตรฐานได้ด้วย API เช่น Instagram API, Facebook API และ YouTube API
กล่าวอีกนัยหนึ่ง โปรแกรมสามารถนำคุณสมบัติหรือข้อมูลจากซอฟต์แวร์อื่นมาใช้เพื่อปรับปรุงคุณสมบัติหรือประสบการณ์ของผู้ใช้เอง แต่แอพจะสร้างคำขอเหล่านี้ ประมวลผล และตอบกลับในแบบที่ผู้อื่นสามารถเข้าใจได้อย่างไร
ขึ้นอยู่กับว่า API ถูกสร้างขึ้นอย่างไร เมื่อพูดถึงการออกแบบ API (application programming interface) เป็นเรื่องปกติที่จะเปรียบเทียบ SOAP กับ REST ซึ่งเป็นกระบวนทัศน์ API ที่โดดเด่นที่สุดสองประการ
ทันทีที่ SOAP APIs (Simple Object Access Protocol) กลายเป็นมาตรฐานทองคำสำหรับบริษัทต่างๆ เช่น Oracle, Sun และ PayPal มีการตอบสนองที่เท่าเทียมกันและตรงกันข้ามในหนึ่งปีหรือหลังจากนั้นต่อ REST API จาก Google, Amazon และ eBay
ในโพสต์นี้ เราจะเปรียบเทียบและเปรียบเทียบ SOAP API กับ REST API เพื่อให้คุณสามารถตัดสินใจได้ว่าสิ่งใดเหมาะสมที่สุดสำหรับวัตถุประสงค์ของคุณ
เราจะเริ่มต้นด้วยการกำหนด API
API คืออะไร?
Application Programming Interface เรียกว่า API โดยพื้นฐานแล้ว API คือชุดของวิธีการและฟังก์ชันที่ช่วยให้สามารถพัฒนาแอปได้ พวกเขาเข้าถึงข้อมูลและฟังก์ชันของโปรแกรม บริการ หรือระบบปฏิบัติการต่างๆ
พวกเขาทำหน้าที่เป็นคนกลางระหว่างระบบซอฟต์แวร์ต่างๆ พวกเขาเปิดใช้งาน "พูดคุย" ระหว่างสองโปรแกรมที่ไม่ได้เชื่อมต่อ
มาดูตัวอย่างของนายหน้าซื้อขายหลักทรัพย์ที่มีส่วนร่วมอย่างแข็งขันในการซื้อขายและตลาดการเงิน คอลเลกชันอัตโนมัติ อัลกอริทึมการซื้อขาย สามารถเชื่อมต่อกับแพลตฟอร์มนายหน้าซื้อขายที่ชื่นชอบของเทรดเดอร์ผ่าน API สิ่งนี้ช่วยให้คุณซึ่งเป็นผู้ค้าทำธุรกรรมทางอิเล็กทรอนิกส์หรือดูใบเสนอราคาและข้อมูลการกำหนดราคาแบบเรียลไทม์
REST คืออะไร?
API "บริการเว็บ" ที่แท้จริงรวมถึง REST (Representational State Transfer) REST API สร้างขึ้นบน URI (Uniform Resource Identifiers ซึ่ง URL เป็นชนิดพิเศษ) โปรโตคอล HTTP และรูปแบบข้อมูล JSON ที่เข้ากันได้กับเบราว์เซอร์อย่างไม่น่าเชื่อ
อาจใช้โปรโตคอล SOAP ตามที่เราระบุไว้แล้ว REST API สามารถสร้างและเติบโตได้ง่าย แต่ก็สามารถมีขนาดใหญ่และยากได้เช่นกัน ทั้งหมดนี้ขึ้นอยู่กับวิธีการสร้าง ขยาย และสิ่งที่พวกเขาตั้งใจจะทำ
ข้อจำกัดด้านทรัพยากร ข้อกำหนดด้านความปลอดภัยที่ลดลง ความเข้ากันได้ของไคลเอ็นต์เบราว์เซอร์ การค้นพบ ความสมบูรณ์ของข้อมูล และความสามารถในการปรับขนาดเป็นเหตุผลบางประการที่คุณต้องการพัฒนา API ให้สงบ ซึ่งเป็นสิ่งที่ใช้กับบริการเว็บจริงๆ
REST เสนอตัวเลือกที่เบากว่า SOAP นั้นใช้งานยากและเป็นภาระสำหรับนักพัฒนาหลายคน ตัวอย่างเช่น การใช้ SOAP กับ JavaScript จำเป็นต้องเขียนโค้ดจำนวนมากเพื่อดำเนินการอย่างง่ายให้เสร็จสมบูรณ์ เนื่องจากจะต้องสร้างโครงสร้าง XML ที่จำเป็นในแต่ละครั้ง
REST (โดยทั่วไป) ใช้ URL ตรงไปตรงมาแทนคำขอ XML แม้ว่าจะมีบางกรณีที่คุณต้องให้รายละเอียดเพิ่มเติม แต่บริการเว็บ RESTful ส่วนใหญ่ใช้เทคนิค URL เท่านั้น
REST สามารถใช้กริยา HTTP 1.1 ทั้งสี่ GET, POST, PUT และ DELETE เพื่อดำเนินการได้ ต่างจาก SOAP ตรงที่ REST ไม่ต้องการคำตอบที่จะอยู่ใน XML
บริการเว็บแบบ REST ที่ส่งออกข้อมูลในรูปแบบ Command Separated Value (CSV), JavaScript Object Notation (JSON) และรูปแบบ Really Simple Syndication (RSS) พร้อมใช้งาน (RSS)
วัตถุประสงค์คือคุณจะได้ผลลัพธ์ที่ต้องการในรูปแบบที่แยกวิเคราะห์ได้ง่ายในภาษาที่คุณใช้สำหรับแอปพลิเคชันของคุณ
คุณสมบัติ
- REST เน้นความเรียบง่ายเหนือสิ่งอื่นใด เนื่องจากโปรโตคอล HTTP
- เว็บเหมาะที่สุดสำหรับ REST เข้ากันได้กับเบราว์เซอร์เนื่องจากใช้ JSON เป็นรูปแบบข้อมูล
- REST มีชื่อเสียงในด้านความสามารถในการปรับขนาดและความเร็วที่โดดเด่น
- การเชื่อมต่อและสถาปัตยกรรมของไคลเอ็นต์-เซิร์ฟเวอร์สามารถเข้าถึงได้มากขึ้นโดย REST API หากเป็น RESTful จะถูกสร้างขึ้นโดยใช้โมเดลไคลเอ็นต์-เซิร์ฟเวอร์นี้ โดยจะมีการรับส่งข้อมูลระหว่างสองฝ่ายผ่านเพย์โหลดข้อมูล
- REST APIs ใช้อินเทอร์เฟซมาตรฐานแบบแยกส่วน ตรวจสอบให้แน่ใจว่าแอปทั้งหมดเชื่อมต่ออย่างเท่าเทียมกันและผ่านเกตเวย์เดียวกัน ปรับปรุงวิธีที่แอปพลิเคชันสื่อสารกับ API
SOAP คืออะไร?
โปรโตคอลของตัวเองที่เรียกว่า SOAP (Simple Object Access Protocol) นั้นซับซ้อนกว่า REST เล็กน้อย เนื่องจากมีการระบุมาตรฐานเพิ่มเติม รวมถึงมาตรฐานที่เกี่ยวข้องกับความปลอดภัยและการส่งข้อความ
บรรทัดฐานโดยธรรมชาติเหล่านี้มาพร้อมกับค่าใช้จ่ายเพิ่มเติมเล็กน้อย อย่างไรก็ตาม สิ่งเหล่านี้อาจเป็นปัจจัยชี้ขาดสำหรับธุรกิจที่ต้องการความปลอดภัย ธุรกรรม และความสามารถในการปฏิบัติตาม ACID (Atomicity, Consistency, Isolation, Durability) ที่ครอบคลุมมากขึ้น
เพื่อประโยชน์ในการเปรียบเทียบนี้ สิ่งสำคัญที่ควรทราบคือ ประโยชน์หลายประการของ SOAP มักไม่ได้ใช้กับแอปพลิเคชันบริการเว็บ ทำให้เหมาะสมสำหรับสถานการณ์ประเภทองค์กรมากขึ้น
ระดับความปลอดภัยที่สูงขึ้น (เช่น เมื่อ a app มือถือ โต้ตอบกับธนาคาร) แอปส่งข้อความที่ต้องการการสื่อสารที่เชื่อถือได้ การโต้ตอบกับระบบเดิม หรือการปฏิบัติตามข้อกำหนดของ ACID เป็นเหตุผลสองสามประการที่คุณต้องการออกแบบแอปพลิเคชันโดยใช้ SOAP API
ความสามารถในการส่งข้อความที่นำเสนอโดย SOAP นั้นใช้ XML ทั้งหมด เทคโนโลยีเก่าที่เข้ากันไม่ได้กับอินเทอร์เน็ต เช่น Distributed Component Object Model (DCOM) และ Common Object Request Broker Architecture ถูกแทนที่ด้วย SOAP เมื่อ Microsoft (CORBA) สร้างขึ้นครั้งแรก
การพึ่งพาการสื่อสารแบบไบนารีทำให้ระบบเหล่านี้ล้มเหลว ทางอินเทอร์เน็ต การส่งข้อความ XML แบบเดียวกับที่ใช้โดย SOAP จะทำงานได้ดีกว่า
คุณสมบัติ
- ความปลอดภัยของ SOAP นั้นเข้มงวดกว่ามาก WS-Security เป็นมาตรฐานในตัวที่ให้ความสามารถในการรักษาความปลอดภัยระดับองค์กรเพิ่มเติมของ SOAP หากจำเป็น นอกเหนือจากการรองรับ SSL
- ใช้เหตุผลสำเร็จ/ลองใหม่อีกครั้งเพื่อประสิทธิภาพการส่งข้อความที่น่าเชื่อถือ เนื่องจาก REST ไม่มีกลไกการส่งข้อความที่เป็นมาตรฐาน จึงสามารถลองใหม่ได้เมื่อการสื่อสารล้มเหลวเท่านั้น แม้เมื่อใช้ตัวกลาง SOAP SOAP ก็มีความน่าเชื่อถือแบบ end-to-end เนื่องจากตรรกะที่ประสบความสำเร็จ/ลองใหม่ในตัว
- SOAP เป็นไปตามมาตรฐาน ACID แล้ว ด้วยการกำหนดวิธีที่ธุรกรรมสามารถโต้ตอบกับฐานข้อมูล การปฏิบัติตามข้อกำหนดของ ACID ช่วยลดความผิดปกติและป้องกันความสอดคล้องของฐานข้อมูล เนื่องจาก ACID มีความระมัดระวังมากกว่าแบบจำลองความสอดคล้องของข้อมูลอื่นๆ จึงมักใช้เมื่อจัดการธุรกรรมที่มีความละเอียดอ่อน ไม่ว่าจะเป็นด้านการเงินหรือด้านอื่นๆ
- โปรแกรมเมอร์เข้าใจได้ง่ายเนื่องจาก SOAP เป็นการสื่อสารแบบ XML ทั้งหมด
- โปรโตคอลการส่งข้อความ XML เป็นส่วนเพิ่มเติมของโปรโตคอล HTTP
- การสื่อสารจากคอมพิวเตอร์เครื่องหนึ่งไปยังคอมพิวเตอร์เครื่องอื่นสามารถเผยแพร่ผ่านการส่งข้อความ SOAP
- สถาปัตยกรรมไคลเอนต์ - เซิร์ฟเวอร์สามารถนำไปใช้ได้เช่นกัน ไคลเอ็นต์สามารถใช้ข้อความโปรโตคอล SOAP เพื่อเรียกโพรซีเดอร์ระยะไกลที่อยู่ฝั่งเซิร์ฟเวอร์
REST Vs SOAP ความแตกต่าง
1 สถาปัตยกรรม
API มีวัตถุประสงค์เพื่อแสดงองค์ประกอบเฉพาะของตรรกะทางธุรกิจของแอปพลิเคชันบนเซิร์ฟเวอร์เป็นหลัก แม้ว่า REST จะใช้ URI เพื่อจุดประสงค์เดียวกัน SOAP ก็ใช้ส่วนต่อประสานบริการสำหรับสิ่งนี้
REST API ถูกสร้างขึ้นหลังจากข้อมูล ในขณะที่ SOAP API ได้รับการพัฒนาหลังจากฟังก์ชันต่างๆ ที่ API แสดงให้เห็น เมื่อเทียบกับ SOAP ซึ่งขับเคลื่อนด้วยฟังก์ชันมากกว่า REST เป็นการออกแบบที่ขับเคลื่อนด้วยข้อมูลมากกว่า
2 แคช
เบราว์เซอร์สามารถใช้ข้อมูลที่ทำเครื่องหมายว่าแคชได้อีกครั้งโดยไม่จำเป็นต้องส่งคำขอใหม่ไปยังเซิร์ฟเวอร์ การประหยัดเวลาและความพยายามเป็นประโยชน์ของสิ่งนี้
การตอบสนองจะไม่ถูกแคชที่ระดับ HTTP เนื่องจากการสืบค้น SOAP ถูกส่งผ่านคำขอ POST ซึ่งมาตรฐาน HTTP ถือว่าไม่มีศักยภาพ หากคุณต้องการใช้การแคช คุณยังต้องสร้างเทคนิคที่จำเป็นเนื่องจาก REST API ไม่รวมการใช้งานนี้
3. ทรัพยากร & แบนด์วิดธ์
เนื่องจากการถ่ายโอนเพย์โหลดแบบซองจดหมายที่ใช้โดย SOAP จึงมีโอเวอร์เฮดเพิ่มขึ้นเล็กน้อย ซึ่งจำเป็นต้องมีแบนด์วิดท์เพิ่มเติม ลักษณะที่มีน้ำหนักเบาของ REST เป็นประโยชน์ในสถานการณ์เหล่านี้ เนื่องจากโดยทั่วไปแล้วจะใช้สำหรับบริการเว็บ
4 ความปลอดภัย
WS-security ซึ่ง SOAP รองรับและละเอียดกว่า SSL เล็กน้อยที่ระดับการส่งข้อมูลเล็กน้อยนั้นเป็นที่ต้องการ การรวมมาตรการรักษาความปลอดภัยระดับองค์กรเข้าด้วยกันก็เหมาะสมที่สุดเช่นกัน
การเข้ารหัสจากต้นทางถึงปลายทางโดยใช้ SSL ได้รับการสนับสนุนโดยทั้ง SOAP และ REST และ REST สามารถใช้ HTTPS ซึ่งเป็นตัวแปรที่ปลอดภัยของโปรโตคอล HTTP
5. การจัดการน้ำหนักบรรทุก
ข้อมูลที่ส่งผ่านอินเทอร์เน็ตเรียกว่าเพย์โหลด เพย์โหลดที่ถือว่า "หนัก" ต้องการทรัพยากรเพิ่มเติม เมื่อเทียบกับ SOAP ซึ่งใช้ XML แล้ว REST มักใช้ JSON และ HTTP เพื่อช่วยลดเพย์โหลด
ไลบรารีไคลเอ็นต์เฉพาะที่มีรหัสที่สร้างขึ้นมักจะต้องใช้โดยไคลเอ็นต์เพื่อเข้าถึง SOAP API เนื่องจากสัญญาการสื่อสารที่เข้มงวดอย่างยิ่ง
ผลลัพธ์ที่ได้คือ SOAP นำเสนอระดับนามธรรมที่น้อยกว่า REST และมีการเชื่อมต่ออย่างใกล้ชิดกับเซิร์ฟเวอร์
ควรใช้ REST เมื่อใด
- การสร้าง API สาธารณะ: REST API เป็นที่ต้องการสำหรับการสร้างบริการเว็บสาธารณะเพราะเห็นว่าใช้งานและปรับใช้ได้ง่ายกว่า SOAP API นอกจากนี้ SOAP ยังมีมาตรการรักษาความปลอดภัยในตัวหลายอย่างที่ REST ไม่มี แม้ว่าคุณลักษณะเหล่านี้จะไม่จำเป็นเมื่อทำงานกับข้อมูลและบริการที่เปิดอยู่
- การสร้างแอพมือถือ: REST เหมาะอย่างยิ่งสำหรับการสร้างแอปพลิเคชันมือถือ เนื่องจากมีขนาดเล็ก มีประสิทธิภาพ ไม่เก็บสถานะ และแคชได้
- การใช้ทรัพยากรเซิร์ฟเวอร์และแบนด์วิดธ์ที่หายาก: คำขอทั้งหมดที่ส่งไปยัง REST API จะต้องไม่มีสถานะ ซึ่งหมายความว่าแต่ละการโต้ตอบจะแยกจากกัน และคำขอและการตอบกลับแต่ละรายการจะมีข้อมูลทั้งหมดที่จำเป็นในการโต้ตอบนั้นให้เสร็จสมบูรณ์ เซิร์ฟเวอร์ไม่บันทึกเรกคอร์ดของคำขอก่อนหน้า เนื่องจากจะถือว่าแต่ละรายการเป็นคำขอใหม่ ส่งผลให้เซิร์ฟเวอร์ต้องการหน่วยความจำน้อยกว่ามากและทำงานได้เร็วขึ้น เนื่องจากคำขอไม่จำเป็นต้องดำเนินการเพิ่มเติมหรือดึงข้อมูลในอดีต
ควรใช้ SOAP เมื่อใด
- การสร้าง API ส่วนตัว โดยเฉพาะอย่างยิ่งสำหรับธุรกิจขนาดใหญ่: SOAP เหมาะอย่างยิ่งสำหรับแอปพลิเคชันขององค์กร เนื่องจากช่วยให้สามารถรับส่งข้อมูลในสภาพแวดล้อมแบบกระจายศูนย์และมีคุณลักษณะด้านความปลอดภัยออนไลน์หลายอย่าง
- การใช้โปรโตคอลการขนส่งอื่นที่ไม่ใช่ HTTP เป็นเลเยอร์พื้นฐาน: SOAP ไม่ได้ขึ้นอยู่กับ HTTP เป็นเลเยอร์พื้นฐาน คุณสามารถใช้ SMTP (Simple Mail Transfer Protocol), JMS (Java Messaging Service) หรือโปรโตคอลการขนส่งอื่น ทั้งนี้ขึ้นอยู่กับแอปพลิเคชันของคุณ
- การทำงานกับการดำเนินการเก็บสถานะ: ตรงกันข้ามกับคำขอไปยัง REST API คำขอไปยัง SOAP API เป็นแบบเก็บสถานะ ซึ่งหมายความว่าเซิร์ฟเวอร์จะบันทึกข้อมูลเกี่ยวกับไคลเอนต์และใช้งานข้ามห่วงโซ่ของคำขอหรือการดำเนินการ แม้ว่าสิ่งนี้จะใช้แบนด์วิดท์และทรัพยากรของเซิร์ฟเวอร์มากกว่า แต่ก็เป็นสิ่งสำคัญสำหรับการดำเนินการตามกิจวัตรหรือการดำเนินการที่เชื่อมโยง เช่น การโอนเงินผ่านธนาคาร
สรุป
การเปรียบเทียบระหว่าง REST และ SOAP API ทำให้ค่อนข้างชัดเจนว่า REST นั้นดีกว่า SOAP ถึงกระนั้นก็มีสถานการณ์ที่จำเป็นต้องใช้ SOAP API ในบางกรณี บริการเว็บถูกสร้างขึ้นโดยการรวม REST และ SOAP API
ดังนั้น กรณีการใช้งานจะเป็นตัวกำหนดว่ารูปแบบ API ใดจะทำงานได้ดีที่สุด
เขียนความเห็น