Tôi có nên khôi phục các cuộc gọi RPC của mình qua HTTP không?

Question

Chúng tôi có các dịch vụ web HTTP là RPC. Chúng trả về XML đại diện cho đối tượng được truy lục hoặc được tạo ra. Tôi muốn biết những lợi thế (nếu có) của "phục hồi" các dịch vụ.

• POST http://www.example.com/createDoodad
• GET http://www.example.com/getDoodad?id=13
• GET http://www.example.com/getWidget?id1=11&id2=45
• POST http://www.example.com/createWidget
• POST http://www.example.com/createSprocked

Một điều tôi thấy là chúng ta không cần đại diện cho MỌI tài nguyên và chúng tôi không cần phải hỗ trợ tất cả các hoạt động (GET, PUT, POST, DELETE) o n tất cả các nguồn lực. Về cơ bản, câu hỏi của tôi là vậy.

Thận trọng với tôi rằng tôi nên sử dụng các dịch vụ an toàn thay vì RPC qua HTTP và những dịch vụ này sẽ là gì?

Answer 1

Đối với tất cả về ngữ nghĩa, URI là chỉ số Tài nguyên thống nhất. HTTP cung cấp các phương thức GET, POST, PUT và DELETE một tài nguyên. Tiêu đề HTTP chỉ định định dạng nào tôi muốn nhận hoặc gửi thông tin. Đây là tất cả có sẵn thông qua giao thức HTTP.

Vì vậy, bạn có thể tái sử dụng cùng một URL mà bạn sử dụng cho đầu ra HTML để nhận XML, JSON theo cách HTTP có nghĩa là được sử dụng.

XML-RPC và SOAP dựa trên các phương thức gọi được mô tả bằng tệp XSD hoặc WSDL trong khi REST dựa trên việc nhận/sửa đổi tài nguyên. Sự khác biệt là tinh tế nhưng rõ ràng. URL chỉ mô tả tài nguyên chứ không phải hành động như thường là trường hợp với SOAP và XML-RPC.

Lợi ích của REST là bạn có thể sử dụng các động từ HTTP để sửa đổi tài nguyên như một cuộc gọi phương thức có thể được đặt tên create/new/add, v.v. có thể chỉ định các định dạng khác nhau trên cùng một tài nguyên theo cách tiêu chuẩn.

Bạn cũng không phải chấp nhận TẤT CẢ động từ trên tài nguyên RESTful, ví dụ nếu bạn muốn tài nguyên chỉ đọc chỉ trả lại mã trạng thái 405 Method Not Allowed trên bất kỳ động từ nào không GET.

Bạn có nên thực hiện lại các cuộc gọi RPC của mình tới REST không? Không, tôi không nghĩ vậy. Những lợi ích không lớn hơn thời gian phát triển. Bạn có nên học REST khi thiết lập một Webservice mới không? Vâng, cá nhân tôi nghĩ như vậy, tiêu thụ một tài nguyên REST sẽ cảm thấy tự nhiên hơn rất nhiều và có thể phát triển nhanh hơn nhiều.

EDIT

Tại sao tôi cảm thấy REST của thắng trên XML-RPC/SOAP là khi phát triển trang web mà bạn đã tổng hợp tất cả các dữ liệu cần thiết cho đầu ra định dạng HTML, bạn cũng viết xác nhận mã cho các cơ quan POST. Tại sao bạn nên thay đổi sang một giao thức khác chỉ vì thay đổi đánh dấu vận chuyển? Bằng cách này khi bạn thiết kế một trang web mới (ngôn ngữ thuyết bất khả tri) nếu bạn thực sự nghĩ về URI là tài nguyên bạn về cơ bản sử dụng URI của bạn như các cuộc gọi phương thức với động từ HTTP tiền tố cuộc gọi phương thức.

Tức là, GET trên/sản phẩm/12 với tiêu đề HTTP Accept: application/json; về cơ bản (tưởng tượng) dịch thành getProducts(12,MimeType.Json).

'phương pháp' này sau đó đã làm một vài điều

1. Kiểm tra nếu chúng tôi hỗ trợ JSON như một kiểu MIME. (Xác thực yêu cầu)
2. Xác thực dữ liệu yêu cầu
3. Dữ liệu tổng hợp cho sản phẩm 12.
4. Định dạng thành JSON và trả về.

Nếu vì một lý do nào trong vòng 4 năm tới YAML sẽ là cơn sốt lớn tiếp theo và một trong những người tiêu dùng của bạn muốn nói chuyện với bạn theo cách đó kiểu MIME này đã được cắm vào dễ dàng hơn nhiều so với web thông thường dịch vụ.

Bây giờ sản phẩm 12 là tài nguyên bạn có thể muốn chấp nhận các loại HTML MIME để hiển thị sản phẩm đã nói, nhưng đối với URI như /product/12/reviews/14/ bạn không cần một đối tác HTML, bạn chỉ muốn người tiêu dùng của mình có thể đăng lên URL đó để cập nhật (PUT)/xóa (DELETE) bài đánh giá của riêng họ. Trong suy nghĩ của URI nghiêm ngặt như tài nguyên, không chỉ là một vị trí của một trang web, và các nguồn lực này lần lượt kết hợp với yêu cầu HTTP đến lời gọi phương thức ở phía máy chủ dẫn đến URL sạch (SEO thân thiện) và (quan trọng hơn) ?) dễ phát triển.

Tôi chắc chắn có các khung công tác bằng bất kỳ ngôn ngữ nào sẽ tự động thực hiện ánh xạ các URI đến các lời gọi phương thức cho bạn. Tôi không thể giới thiệu một kể từ khi tôi thường tung ra của riêng tôi.

ASP.NET MVC cũng hoạt động trên cùng một nguyên tắc, nhưng theo ý kiến ​​của tôi, nó không tạo ra các URI RESTful. ASP.NET MVC làm cho phần động từ của URI theo mặc định đã nói rằng nó là tốt để lưu ý rằng không có nghĩa là ASP.NET MVC lực lượng này (hoặc bất cứ điều gì cho rằng vấn đề) khi bạn.

Nếu bạn đang đi để lựa chọn một khuôn khổ tại ít nhất là rất họ nên:

1. Bind URI của các phương pháp trên máy chủ
2. Hỗ trợ đối tượng để JSON/XML vv serialization. Đó là một nỗi đau nếu bạn phải viết điều này cho mình mặc dù, phụ thuộc vào ngôn ngữ, không cần thiết tất cả các quá khó khăn.
3. Hiển thị một số loại trình trợ giúp yêu cầu an toàn loại để giúp bạn xác định những gì được yêu cầu mà không cần phân tích cú pháp tiêu đề HTTP theo cách thủ công.

Answer 2

Hãy thử dùng các động từ ra khỏi URL của bạn:

• POST http://www.example.com/Doodad
• GET http://www.example.com/Doodad/13
• GET http://www.example.com/Widget/11/45
• POST http://www.example.com/Widget
• POST http://www.example.com/Sprocked

Answer 3

Chuỗi truy vấn không được sử dụng để truy cập tài nguyên theo cách phân cấp, không truy vấn.Chuỗi truy vấn thường bị bỏ qua khi lưu vào bộ nhớ cache, điều này rất nguy hiểm và chậm.