ArcGIS REST so với API SOAP


27

Khi nào thì thích hợp để sử dụng API REST của ArcGIS Server so với API SOAP và ngược lại? Bạn thấy lợi thế của cái này hơn cái kia là gì?

Ví dụ: dịch vụ SOAP có thể được sử dụng làm Tham chiếu dịch vụ để tích hợp vào Visual Studio. Có bất cứ điều gì có sẵn sẽ cung cấp cho bạn mức độ tích hợp với REST không?

Thông tin thêm: Dịch vụ GIS ArcGIS


3
Nếu bạn muốn hủy một công việc gp, hiện tại bạn sẽ cần sử dụng SOAP.
Kirk Kuykendall

Câu trả lời:


18

Đây là một câu hỏi hay. Trong khi tôi thích REST, tôi không thấy cách yêu cầu giá trị Z và M cho hình học. Có vẻ như điều này là có thể với SOAP bằng cách sử dụng đối tượng PointN . Sẽ thật tuyệt khi thấy câu hỏi này phát triển để liệt kê nhiều sự khác biệt.

Một yếu tố khác là những gì khách hàng bạn cần hỗ trợ - nếu đó chỉ là Silverlight, thì SOAP hấp dẫn hơn rất nhiều.

Tôi đã phát triển các dịch vụ của SOE và GP gửi các đối tượng phức tạp qua Json.NET. Những đối tượng này được Silverlight tiêu thụ dễ dàng, nhưng có vẻ như một ứng dụng javascript sẽ có thời gian khó khăn hơn nhiều .


12

REST - Chuyển giao nhà nước đại diện

Về cơ bản REST có nghĩa là mỗi URL duy nhất là một đại diện của một số đối tượng. Bạn có thể lấy nội dung của đối tượng đó bằng HTTP GET, để xóa nó, sau đó bạn có thể sử dụng POST, PUT hoặc DELETE để sửa đổi đối tượng (trong thực tế hầu hết các dịch vụ đều sử dụng POST cho việc này).

SOAP - Giao thức truy cập đối tượng đơn giản

SOAP chủ yếu được sử dụng cho các ứng dụng Enterprise để tích hợp các loại rộng và không. các ứng dụng và xu hướng khác là tích hợp với các hệ thống cũ, v.v. Google nhất quán trong việc triển khai các dịch vụ web của họ bằng SOAP (trừ Blogger)

SOAP chiến thắng với GeoProcessing với ArcGIS Server +1 cho Kirk


Tôi nghĩ "Đơn giản" là một cách viết sai trong SOAP (ngoại trừ có thể khi nhấp qua trình hướng dẫn VS để thực hiện). Việc sử dụng REST có vẻ dễ dàng hơn, nhưng cuối cùng nó phụ thuộc vào những khách hàng bạn cần hỗ trợ (như Kirk đã nói ở trên).
Bratch

2
Google có chỉ lăm API SOAP, và 45 API REST: programmableweb.com/apis/directory/...
SCW

7

Ở các khách hàng trước, chúng tôi đã xem xét điều này từ lâu và đối với họ, đó là SOAP có quá nhiều thời gian phát triển và REST dễ dàng cho một tổ chức thực hiện.

Có thể tranh cãi rằng SOAP không thực sự là dịch vụ web ...

Đây là một số đối số cho bạn:

SOAP / REST



3

Ngày càng có nhiều người chuyển sang các dịch vụ REST vì chúng rất dễ sử dụng và mã trong khi SOAP rất thik và chậm so với REST. Trong tương lai gần, chúng ta sẽ chứng kiến ​​sự di cư lớn và (Hy vọng) SOAP sẽ DIE


Ngày càng có nhiều người chuyển sang các dịch vụ mà họ nghĩ là RESTful nhưng thực tế lại không
nmtoken
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.