Tại sao không có hỗ trợ loại WSDL cho Api Web?

Vì vậy, tôi mới bắt đầu với .Net WebApi và một điều mà tôi nhận thấy ngay lập tức là không có Hợp đồng xác định API trông như thế nào và nên được sử dụng (Yêu cầu / Phản hồi từ mỗi Hành động), điều này thường ở dạng một WSDL cho WCF / Xà phòng.

Dường như với tôi như thế này là một thứ gì đó sẽ rất có giá trị và làm cho cuộc sống của người tiêu dùng API của bạn dễ dàng hơn rất nhiều.

Có một lý do không có một? Có một mô hình lập trình hoặc nguyên tắc mà tôi không biết? Có cách nào tôi có thể tạo ra một?

SÁNG TẠO SOAP, REST VÀ NHÂN DÂN

SOAP cần một tài liệu mô tả như WSDL vì mỗi tài nguyên có thể được sử dụng với các thông điệp khác nhau, không có định nghĩa nào về giao thức về các ràng buộc đối với các tên / thông điệp có thể mà bạn có thể thao tác với tài nguyên.

Ví dụ: trong SOAP, dịch vụ web của bạn cho phép khách hàng thao tác với người dùng có thể hiển thị thao tác tạo người dùng trong nhiều thông báo khác nhau, như:

addUser
createUser
insertUser

Tất nhiên, đây chỉ là một vài thông báo mẫu, bởi vì tôi đã thấy rất nhiều tên phương thức dịch vụ web hài hước. Có những người thực sự sáng tạo ra khỏi đó.

Mặt khác, nếu bạn đang phơi bày hệ thống cơ bản của mình bằng cách sử dụng web api thực sự tôn trọng các nguyên tắc REST, thì khách hàng chỉ cần biết rằng bạn có tài nguyên có tên Người dùng, vì có 99% khả năng bạn có thể tạo người dùng trong việc này đường

POST /Users

Và điều này xảy ra cho mỗi thao tác bạn muốn hiển thị bằng SOAP hoặc web api REST.

Mặc dù là một giao thức SOAP, trong đó hạn chế những gì bạn có thể hoặc không thể làm và là REST một kiến ​​trúc kiểu, để lại nhiều điểm mở về cách thực hiện. Có những nỗ lực để xác định các quy ước về cách phơi bày và tiêu thụ apis web REST.

MÔ TẢ MỘT WEB API REST

Trong lĩnh vực làm thế nào để mô tả một web api REST tôi có thể trích dẫn Swagger . Đây không phải là một nỗ lực để tạo WSDL như web api REST, nhưng đó là một nỗ lực tốt để tạo một tiêu chuẩn mở để mô tả web apis REST.

Swagger là một đặc tả và triển khai khung hoàn chỉnh để mô tả, sản xuất, tiêu thụ và trực quan hóa các dịch vụ web RESTful.

Tôi sử dụng Swagger rất nhiều và thực sự yêu thích nó, chủ yếu là vì Swagger UI cho phép bạn tạo một tài liệu và bảng điều khiển trực tiếp đẹp cho api web của bạn.

Có nhiều triển khai Swagger cho hầu hết các ngôn ngữ: C #, Java, Python, Ruby, v.v.

Nếu bạn đang sử dụng API Web .NET .NET, có một số dự án để tự động tạo đặc tả Swagger, như Swagger.NET

TẠO KHÁCH HÀNG ĐẾN MỘT WEB API REST

Bởi vì các ràng buộc của REST, như bộ động từ giới hạn (GET, POST, PUT, DELETE, v.v.) không quá khác biệt để tạo thư viện máy khách cho REST api web.

Các dự án như WebApiProxy có thể dễ dàng tạo ứng dụng khách làm C # và Javascript.

ĐIỀU KIỆN CHO WEB API REST

Để giữ cho cuộc sống của chúng tôi là các nhà phát triển dễ dàng hơn, hãy xác định rõ một số quy ước về cách ứng dụng web REST của chúng tôi sẽ hoạt động, nỗ lực tốt nhất tôi biết trong lĩnh vực này là sách Apigee - Web Api Design rất tốt . Sách điện tử không phải là một nỗ lực để tạo ra một cuốn kinh thánh hay một câu thần chú về cách thiết kế api của bạn, mà là một tập hợp các quy ước được quan sát trong các trang web REST apis lớn, như Twitter, Facebook, Linkedin, Google, v.v.

Tóm lại, vì SOAP được thiết kế để tự mô tả: Điểm cuối SOAP thường bao gồm một wsdl mô tả những hoạt động mà nó cung cấp và cách thức dữ liệu (bằng phương tiện của XSD nhúng) mà mỗi hoạt động thực hiện và / hoặc trả về.
Do tính tự mô tả này, một ứng dụng như Visual Studio có thể tạo proxy webservice cho nó.

Ngoài ra, có một số phần mở rộng cho SOAP (thông số kỹ thuật WS- *) cho phép mã hóa hoặc hành vi giao dịch được sử dụng với SOAP. Ý tưởng là bạn có thể sử dụng SOAP làm cửa hàng một cửa của mình để tạo các dịch vụ web cấp doanh nghiệp.

Mặt khác...

WebAPI được thiết kế để cung cấp dịch vụ REST. Định dạng giao tiếp cho REST thường là JSON hoặc xml đơn giản - mặc dù nó thực sự không quan trọng, nó thậm chí có thể là văn bản thuần túy. Các dịch vụ REST tuân theo một triết lý hoàn toàn khác: chúng có nghĩa là nhẹ để chúng có thể dễ dàng được sử dụng bởi các tập lệnh phía máy khách như một phần của giải pháp AJAX hoặc bởi các thiết bị di động.
Như vậy, cần phải giữ mức độ lễ ở mức tối thiểu, bao gồm cả tự mô tả. Ngoài ra, ngay cả khi bạn muốn, hầu hết các định dạng giao tiếp được sử dụng trong các dịch vụ REST (như JSON) đều không có cách mô tả chính thức về nội dung của chúng.

Tóm tắt, bạn có thể nói rằng dịch vụ web SOAP thường được sử dụng để tích hợp các giải pháp (có thể khác nhau), trong khi các dịch vụ REST phù hợp hơn để cung cấp liên lạc giữa các phần của cùng một giải pháp.

API SOAP / WS- * và RESTful không giống nhau. Nếu bạn muốn xây dựng các API hỗ trợ SOAP / WS- * WSDL, công cụ được lựa chọn trong ngăn xếp của Microsoft là WCF, được gắn với tùy chọn liên kết HTTP (có các tùy chọn liên kết XML và JSON, XML là tùy chọn hỗ trợ WSDL).

Trong thực tế, việc tiêu thụ WSDL từ một ngôn ngữ hoặc nền tảng triển khai khác đã có vấn đề. Các lớp bảo mật WS- * trên đầu trang thậm chí còn hơn thế.

Kinh nghiệm của riêng tôi chủ yếu là với .Net, Node, Java và PHP về vấn đề này và tôi có thể nói rằng khi bạn có các nền tảng không phải xác định chi tiết về loại con hoặc sẽ sử dụng "Object" làm định nghĩa, nó có vấn đề để nói rằng ít nhất. Ngoài ra, phần lớn không ai thực sự hiểu tất cả SOAP / WS- * phụ thuộc nhiều vào công cụ để làm cho nó hoạt động. Công cụ này có rất nhiều chi phí, và các hệ thống khác nhau hoạt động khác nhau.

Đây là một số lý do mọi người tìm cách thử triển khai đơn giản hơn. Các dịch vụ REST (API Web ala) cung cấp các điểm cuối xung quanh các đối tượng / trạng thái. Ý tưởng là dễ dàng hơn để xác định một tập hợp các cấu trúc đối tượng đơn giản hơn được biểu thị theo định dạng JSON và các điểm cuối để sử dụng chống lại các cấu trúc này hơn là cố gắng sử dụng WSDL từ môi trường ngoài hành tinh không hoạt động, sau đó thử tìm hiểu và giải quyết vấn đề

Trớ trêu thay, đây là một trong những lĩnh vực tôi đã sử dụng Node rất nhiều như một dịch vụ dịch thuật, đơn giản vì nó đủ linh hoạt để chấp nhận triển khai bẩn như một khách hàng và tôi có thể viết các ứng dụng khách đơn giản chống lại tải trọng thích nghi của mình hoạt động tốt hơn. EX: C # lấy văn bản JSON, tôi sử dụng JSON.Net để chuyển đổi thành biểu diễn đối tượng mà tôi đã xác định thực sự hoạt động khi tôi không thể sử dụng nhập WSDL.

Trong thực tế điều này xảy ra rất nhiều.

Mặc dù rất nhiều câu trả lời ở đây rất hay, tôi nghĩ câu trả lời đơn giản hơn nhiều: bạn đang nhìn sai công nghệ cho công việc.

Nếu bạn đang tìm cách xây dựng một dịch vụ SOAP, bạn thực sự nên gắn bó với WCF. Đây vẫn là một khuôn khổ rất mạnh mẽ, Microsoft vẫn đang tích cực phát triển nó, không có thông báo nào được đưa ra để chúng tôi nghĩ rằng nó sẽ đi đến bất cứ đâu trong tương lai, và nó đã được thực hiện với ý nghĩ này. API Web hoàn toàn không thay thế WCF (mặc dù có lẽ nó có xu hướng hơn WCF).

API Web từng là một phần của WCF, nhưng nó đã được chuyển sang gia đình ASP.NET chính xác là BECAUSE, nó không thực sự phù hợp với các công nghệ WCF khác. API Web quan tâm nhiều hơn đến việc sử dụng HTTP làm giao thức ứng dụng hơn là giao thức truyền. Trong API Web, các động từ HTTP là vua, trong WCF HTTP chỉ phục vụ để kích hoạt giao thức SOAP.

Đừng đổ lỗi API Web vì đã không cho khả năng thực hiện một số điều mà nó không được thực hiện.