คอฟฟี่เบรค #31 9 ข้อผิดพลาดในอาชีพที่ Developer ทุกคนควรหลีกเลี่ยง เหตุใดสถาปัตยกรรม REST API จึงได้รับความนิยม

9 ข้อผิดพลาดในอาชีพที่นักพัฒนาซอฟต์แวร์ทุกคนควรหลีกเลี่ยง

ที่มา: Infoworld เอาตรงๆนะ บางท่านเริ่มเรียนการเขียนโปรแกรมเพราะคุณหรือพ่อแม่คิดว่าการสร้างรายได้มหาศาลจะง่ายกว่าสำหรับคุณ คุณไม่ค่อยสนใจคอมพิวเตอร์ในโรงเรียน และคุณไม่สนุกกับการพัฒนาซอฟต์แวร์มากนัก หากสิ่งนี้เป็นจริงก็หมายความว่าคุณจะเป็นโปรแกรมเมอร์ธรรมดา ๆ ตลอดไป ใช่ คุณจะได้รับเงินที่ดีเพราะอุตสาหกรรมของเราสนับสนุน แต่บทความนี้ไม่เหมาะกับคุณ แต่ถ้าคุณถูกลงโทษตั้งแต่ยังเป็นเด็กเพราะแยกอุปกรณ์อิเล็กทรอนิกส์เพื่อดูว่ามันทำงานอย่างไร... หากคุณใช้เวลาครึ่งคืนบนอินเทอร์เน็ตเพื่อเรียนรู้วิธีสร้างวิดีโอเกม... หากคุณใช้เวลาว่างอันมีค่าเพื่อเรียนรู้เกี่ยวกับอะไร ไม่มีใครถามคุณ...บทความนี้เหมาะสำหรับคุณ คุณต้องเปลี่ยนการรับรู้ในอาชีพของคุณ คุณไม่ได้เขียนโค้ดเพื่อความสนุกสนานอีกต่อไป แต่คุณทำเพื่อเงิน เพื่อความสนุกสนาน คุณสามารถสนับสนุนโครงการส่วนตัวของคุณได้ แต่โปรดให้แน่ใจว่าคุณอย่างน้อยก็สนุกกับงานประจำวันของคุณ ถ้าไม่ก็หาสถานที่ที่ดีกว่าถ้าเป็นไปได้ เป้าหมายของคุณควรจะคือการเปิดกองทุนเกษียณอายุ ใส่เงินหลังหักภาษีทั้งหมดลงไป ซื้อบ้าน รถยนต์ และทำตามที่คุณต้องการ บางทีการเดินทาง ในขณะเดียวกัน คุณต้องคิดถึงอาชีพของคุณ ไม่ใช่แค่งานปัจจุบันของคุณ ในการทำเช่นนี้ คุณต้องหลีกเลี่ยงข้อผิดพลาดทั้งเก้าประการ ซึ่งเราจะหารือกันในตอนนี้

หลุมพราง #1: อย่าจมอยู่กับเทคโนโลยีเดียวนานเกินไป

ฉันเข้าใจ. คุณชอบ C# หรือ Java หรือ JavaScript, Python หรือ Cobol แต่เทคโนโลยีส่วนใหญ่มีวงจรชีวิตของการนำไปใช้ จุดสูงสุด การเอาท์ซอร์ส เฉพาะกลุ่ม และล้าสมัย ฉันหมายความว่า ถ้าคุณรู้จักโคบอลในช่วงทศวรรษ 1980 คงจะดีมาก แต่โปรแกรมเมอร์ Cobol ไม่ได้ทำเงินมากนักในปัจจุบัน นั่นคือประเด็นก็คือการรู้ภาษาโปรแกรมเพียงภาษาเดียวไม่ช้าก็เร็วคุณจะต้องลดค่าใช้จ่ายย้ายไปเมืองที่ถูกกว่าเพราะคุณจะได้รับรายได้น้อยลง

หลุมพรางหมายเลข 2: อย่าเป็นผู้ผูกขาดด้านไอที

คุณต้องป้องกันความเสี่ยงการลงทุนของคุณ อาจดูเหมือนว่าคุณเพียงแค่ต้องเป็นผู้เชี่ยวชาญในเทคโนโลยีที่ครองตลาดในปัจจุบัน แต่แล้วคุณก็จะต้องเผชิญกับการแข่งขันมากมาย นอกจากนี้ เมื่อความต้องการความเชี่ยวชาญพิเศษของคุณลดลง คุณควรมีแผนออกจากระบบอยู่แล้ว ตัวอย่างเช่น ฉันเป็นคนที่คลั่งไคล้ C++ เมื่อ Java เปิดตัว ฉันเรียนภาษาจาวา ไม่กี่ปีที่ผ่านมา ทุกคนเริ่มพูดถึง Ruby ในฐานะดาวรุ่งดวงใหม่ในบรรดาภาษาการเขียนโปรแกรม และเมื่อถึงจุดหนึ่งดูเหมือนว่า Perl จะไปถึงระดับเดียวกับ Java การทำนายอนาคตเป็นเรื่องยาก ดังนั้นการป้องกันความเสี่ยงจึงเป็นวิธีที่ปลอดภัยที่สุดเพื่อให้แน่ใจว่ามีความเกี่ยวข้องในตลาดงาน

หลุมพราง #3: อย่ายึดติดกับแฟชั่น

ไม่ช้าก็เร็วเวทย์มนตร์ก็หายไป ผู้คนจะไม่จ้างนักพัฒนา Groovy หรือ Ruby หากเจ้านายของคุณอนุญาตให้คุณใช้ภาษาเดิมในโครงการได้ อาจเป็นเพราะเขาไม่สนใจหรือแค่ไม่มีความรู้ เรียนรู้และใช้เทคโนโลยีใหม่ล่าสุด เตรียมพร้อมที่จะเป็นหนึ่งในคนกลุ่มแรก ๆ ที่รู้เกี่ยวกับพวกเขาและเป็นผู้เชี่ยวชาญในเรื่องนี้ ในทางกลับกัน ให้เตรียมพร้อมที่จะทำการเปลี่ยนแปลงครั้งใหญ่หากความต้องการความเชี่ยวชาญพิเศษของคุณลดลง มีเทคโนโลยีใหม่อื่นๆ ที่น่าสนใจอยู่เสมอ ไม่ว่าจะเป็นภาษาหรือฐานข้อมูล

หลุมพราง #4: แพ้กฎเกณฑ์

ทุกองค์กรไม่ว่าใหญ่หรือเล็ก ต่างก็มีกฎเกณฑ์ในสำนักงานของตัวเอง คุณจะต้องศึกษาและปฏิบัติตามพวกเขา ไม่เช่นนั้นคุณจะกลายเป็นเบี้ยในเกมของคนอื่นหรือพบว่าตัวเองโดดเดี่ยวในทีม หากคุณสนใจในอาชีพและความสัมพันธ์ที่มีประสิทธิผลในที่ทำงาน ให้เรียนรู้ที่จะปฏิบัติตามกลยุทธ์การป้องกันในกฎของที่ทำงาน

หลุมพราง #5: การไม่สนใจธุรกิจ

“ฉันเป็นแค่นักพัฒนา ฉันไม่สนใจธุรกิจ” นี่คือถนนที่ไม่มีที่ไหนเลย คุณต้องเรียนรู้ที่จะนับ บริษัทของคุณไปได้ดีหรือเปล่า? วัตถุประสงค์ทางธุรกิจหลักคืออะไร? โครงการที่สำคัญที่สุดของเธอคืออะไร? เทคโนโลยีหรือซอฟต์แวร์ช่วยให้บรรลุเป้าหมายได้อย่างไร? บริษัทของคุณเหมาะสมกับอุตสาหกรรมโดยรวมอย่างไร? หากคุณไม่ทราบคำตอบสำหรับคำถามเหล่านี้ คุณจะต้องทำงานในโครงการที่ไม่สำคัญสำหรับคนไม่สำคัญในบริษัทที่ไม่สำคัญด้วยเงินจำนวนเล็กน้อย

หลุมพรางหมายเลข 6: แนวคิดเรื่อง “ความสามัคคีของสหภาพแรงงาน”

เมื่อตอนที่ฉันยังเป็นเด็ก เพื่อนร่วมงานคนหนึ่งของฉันเป็นคนที่วางแผนเกือบทุกอย่างล่วงหน้าหกเดือน เขาทำผิดพลาดในการไปพักร้อน ดังนั้นฉันจึงทำโปรเจ็กต์ทั้งหมดเสร็จภายในสองสัปดาห์ แต่เหลือให้เขาทำงานอีกชิ้นหนึ่ง ฉันคาดหวังให้เขามีความสุขกับมัน ปรากฎว่าเขาไม่มีความสุข ทุกอย่างจบลงด้วยการที่เขาใช้ทุกโอกาสเพื่อทำให้ฉันถูกไล่ออก นี่กลายเป็นเป้าหมายหลักของเขา เขายังบ่นเกี่ยวกับฉันกับผู้กำกับคนใหม่ของเราด้วย แน่นอนฉันทำทุกงานของฉัน ฉันเป็นผู้ริเริ่ม ฉันมักจะค้นหาวิธีใหม่ๆ ในการทำสิ่งต่างๆ ให้ดีขึ้นและเร็วขึ้น และแก้ไขปัญหาอยู่เสมอ เขาเกษียณไม่นานหลังจากที่ฉันออกไปทำงานอื่น หลายครั้งที่ฉันเห็นเขาในร้านกาแฟและเราแกล้งทำเป็นว่าเราไม่รู้จักกัน นี่คงไม่ใช่ครั้งสุดท้ายที่ฉันเจองานประเภทนี้: "ทำสิ่งต่าง ๆ ช้าๆ ไม่งั้นทุกอย่างจะแย่ลง" คำแนะนำของฉัน: เขียนโค้ดให้ถูกต้อง แต่เตรียมพร้อมสำหรับสิ่งที่ไม่คาดคิด หากปัญหาไม่สามารถแก้ไขได้ ให้ปิดประตูไปเลย เพราะบริษัทของคุณไม่ใช่บริษัทเดียวในตลาด

หลุมพรางหมายเลข 7: คุณไม่รู้คุณค่าของตัวเอง

“ฉันไม่ได้มาที่นี่เพื่อเงิน” ถ้าอย่างนั้นก็ทำงานอดิเรก อย่าไปทำงานทุกวันโดยคิดถึงเงินเดือนครั้งต่อไป คุณไม่ควรไปทำงานหากคุณมีรายได้น้อยกว่าคนอื่น 50% รู้คุณค่าของตัวเองและอย่าประมาทมัน

หลุมพราง #8: ปฏิบัติต่องานของคุณเหมือนงาน

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

หลุมพรางหมายเลข 9: คุณคิดว่ามันเกี่ยวกับเงินเท่านั้น

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

เหตุใดสถาปัตยกรรม REST API จึงได้รับความนิยม

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

API คืออะไร?

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

ลองใช้ตัวอย่างจริง:

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

API ประเภทใดบ้างที่มี?

สถาปัตยกรรม API สามารถนำมาใช้ได้สองวิธีหลัก: หนึ่งในวิธีการใช้งานการถ่ายโอนข้อมูลเหล่านี้คือ SOAP และวิธีหลักอีกวิธีหนึ่งคือ REST เราได้กำหนดไว้แล้วว่า API ให้การสื่อสารระหว่างสองแอปพลิเคชัน ตอนนี้เราจะเรียนรู้ว่า SOAP และ REST เหมาะสมกับสถาปัตยกรรมการสื่อสารอย่างไร

สบู่ API

SOAP (Simple Object Access Protocol) เป็นบริการบนเว็บที่ปฏิบัติตามข้อกำหนดเฉพาะด้วยหลักการสื่อสารบางอย่างที่สร้างขึ้นระหว่างส่วนศูนย์กลางที่เรียกว่า W3C และชุดข้อกำหนดหลัก ชุดนี้ประกอบด้วย:

• สบู่
• WSDL
• อุดดี

SOAP เป็นโปรโตคอลที่กำหนดวิธีที่สองแอปพลิเคชันจะสื่อสารกัน แอปพลิเคชันสองตัวจะต้องเป็นไปตามรูปแบบทั่วไปเมื่อสื่อสารกัน และรูปแบบทั่วไปนี้จะต้องเป็นไปตามภาษา XML XML ใน SOAP API ต้องเป็นไปตามมาตรฐาน SOAP Message ซึ่งประกอบด้วย Envelop, Header และ Body

ส่วนที่เหลือ API

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

อินเทอร์เฟซแบบรวม

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

ไร้สัญชาติ

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

ความสามารถในการแคช

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

ระบบหลายระดับ

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

รหัสตามคำขอ

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

เหตุใด REST API จึงถูกใช้บ่อยขึ้นเรื่อย ๆ

REST ส่วนใหญ่ใช้งานง่ายกว่า ยืดหยุ่นกว่า และมีข้อดีมากกว่า SOAP หลายประการ ตัวอย่างเช่น คุณไม่จำเป็นต้องมีเครื่องมือราคาแพงในการโต้ตอบกับบริการเว็บใดๆ สถาปัตยกรรม REST นั้นเรียบง่ายกว่า สามารถปรับแต่งได้ง่าย และไม่ต้องใช้ทักษะพิเศษเมื่อสร้างแบบจำลองการสื่อสาร มีประสิทธิภาพในการใช้งานเนื่องจากสามารถใช้ฝั่งไคลเอ็นต์ของเซิร์ฟเวอร์เพื่อจัดเก็บข้อมูลที่เกี่ยวข้องกับไคลเอ็นต์ได้ REST ใช้รูปแบบข้อความที่เล็กลงและให้การโต้ตอบที่เร็วขึ้น เนื่องจากไม่ต้องการการประมวลผลที่ใช้เวลานาน REST นั้นใกล้เคียงกับเทคโนโลยีเว็บอื่น ๆ มากขึ้นเมื่อพูดถึงปรัชญาการออกแบบ

สบู่หรือส่วนที่เหลือ?

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