ArcGIS REST กับ SOAP API

เมื่อใดจึงควรใช้ ArcGIS Server REST APIกับSOAP APIและในทางกลับกัน คุณเห็นว่าอะไรคือข้อดีของอีกข้อหนึ่ง?

ตัวอย่างเช่นบริการ SOAP สามารถใช้เป็นการอ้างอิงบริการเพื่อรวมเข้ากับ Visual Studio มีอะไรที่จะให้ระดับการรวมกับ REST หรือไม่?

ข้อมูลเพิ่มเติม: บริการ ArcGIS GIS

นี่เป็นคำถามที่ดี ขณะที่ฉันชอบ REST ฉันไม่เห็นวิธีขอค่า Z และ M สำหรับรูปทรงเรขาคณิต ลักษณะเช่นนี้เป็นไปได้ด้วยสบู่ใช้วัตถุ PointN มันจะเป็นการดีถ้าเห็นคำถามนี้วิวัฒนาการเพื่อแสดงความแตกต่างเพิ่มเติม

ปัจจัยอีกประการหนึ่งคือสิ่งที่ลูกค้าต้องการการสนับสนุน - หากเป็นเพียง Silverlight ดังนั้นสบู่จึงน่าสนใจยิ่งขึ้น

ฉันได้พัฒนาบริการของ SOE และ GP ที่ส่งวัตถุที่ซับซ้อนผ่าน Json.NET วัตถุเหล่านี้มีการบริโภคได้อย่างง่ายดายโดย Silverlight แต่มันดูเหมือนว่าลูกค้าจาวาสคริปต์จะมีช่วงเวลาที่ยากมาก

REST - การโอนย้ายสถานะผู้แทน

ส่วนที่เหลือโดยทั่วไปหมายความว่าแต่ละ URL ที่ไม่ซ้ำกันเป็นตัวแทนของวัตถุบางอย่าง คุณสามารถรับเนื้อหาของวัตถุนั้นโดยใช้ HTTP GET เพื่อลบออกจากนั้นคุณอาจใช้ POST, PUT หรือ DELETE เพื่อแก้ไขวัตถุ (ในทางปฏิบัติบริการส่วนใหญ่ใช้ POST สำหรับสิ่งนี้)

SOAP - โปรโตคอลการเข้าถึงวัตถุอย่างง่าย

SOAP ส่วนใหญ่จะใช้สำหรับแอปพลิเคชันองค์กรเพื่อรวมประเภทที่หลากหลายและไม่ใช่ แอปพลิเคชันและแนวโน้มอื่นคือการรวมเข้ากับระบบเดิมเป็นต้น Google มีความสอดคล้องในการใช้บริการเว็บโดยใช้ SOAP (ยกเว้น Blogger)

SOAP ชนะด้วย GeoProcessing กับ ArcGIS Server +1 สำหรับ Kirk

ที่ลูกค้าก่อนหน้านี้เราดูที่เรื่องนี้มานานและนานสำหรับพวกเขาก็คือ SOAP นั้นมีเวลาในการพัฒนามากเกินไปและ REST นั้นง่ายสำหรับองค์กรที่จะนำไปใช้

มันเป็นเรื่องที่ถกเถียงกันอยู่ว่า SOAP ไม่ได้เป็นบริการบนเว็บเช่นกัน ...

นี่คือข้อโต้แย้งสำหรับคุณ:

SOAP / REST

ตอนนี้คุณสามารถยกเลิกงานและส่งคืน Z และ M ตั้งแต่ ArcGIS REST API 10.1

ส่งงาน GP (ตอนนี้มีตัวเลือกเพื่อ returnZ และ returnM)

ยกเลิกงาน GP

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