Lý do sử dụng WADL là gì?

Để mô tả RESTful, chúng ta có thể nói rằng mọi tài nguyên đều có URI của riêng nó. Sử dụng HTTP GET, POST, PUT và DELETE, chúng tôi có thể hoạt động trên các tài nguyên này. Tất cả các tài nguyên đều mang tính đại diện. Bất cứ ai muốn sử dụng tài nguyên của chúng tôi có thể làm như vậy thông qua trình duyệt hoặc ứng dụng khách REST.

Đó là ý tưởng chính của một kiến ​​trúc RESTful. Kiến trúc này cho phép các dịch vụ trên internet. Vậy tại sao kiến ​​trúc này lại cần WADL? WADL cung cấp những gì mà HTTP tiêu chuẩn không cung cấp? Tại sao WADL cần tồn tại?

Mục đích của WADL là xác định hợp đồng . Hợp đồng quy định cách một bên có thể gọi cho bên khác.

Khi bạn tạo một ứng dụng web từ đầu, bạn không cần hợp đồng và WADL .

Khi bạn tích hợp hệ thống của mình với hệ thống khác và bạn có thể giao tiếp rõ ràng với nhóm phát triển của họ, bạn không cần hợp đồng và WADL (vì bạn có thể gọi điện để làm rõ mọi thứ).

Tuy nhiên, khi bạn tích hợp một hệ thống doanh nghiệp phức tạp với một số hệ thống doanh nghiệp phức tạp khác được duy trì bởi một số công ty khác nhau (hoặc các tổ chức liên bang), thì hãy tin tôi rằng bạn muốn có một hợp đồng giao tiếp được xác định chặt chẽ nhất có thể. Sau đó, bạn cần WADL hoặc Open Specification. Cần nó tệ .

Những người có nền tảng doanh nghiệp yếu có xu hướng coi toàn bộ CNTT như một tập hợp các ứng dụng web riêng biệt được phát triển độc lập. Nhưng thực tế doanh nghiệp đôi khi rất khó khăn. Đôi khi bạn thậm chí không thể gọi hoặc viết thư cho những người đang phát triển ứng dụng mà bạn phải tích hợp. Đôi khi bạn giao tiếp với một ứng dụng cũ không còn được duy trì - nó chỉ chạy và bạn cần tìm ra cách giao tiếp với nó đúng cách. Trong điều kiện như vậy, bạn cần một hợp đồng vì nó tiết kiệm cho bạn .

Trên thực tế, tạo khách hàng là đặc điểm phụ của định nghĩa hợp đồng. Nó chỉ là một món đồ chơi. Hợp đồng buộc những người giao tiếp tồi phải truyền đạt các quy tắc tích hợp một cách rõ ràng. Đây là lý do chính để sử dụng WADL hoặc Open Specification hoặc bất cứ thứ gì.

Sử dụng WADL ngụ ý rằng bạn có thể đủ khéo léo để thực sự xác định dữ liệu / tài liệu bạn đang truyền qua lại. Giả sử bạn đang chuyển một số đoạn XML, chúng thực sự có thể là một phần của một lược đồ đã xác định.

Tôi có sử dụng DL để tạo mã hay không không quan trọng lắm. Điều quan trọng, theo ý kiến ​​chủ quan của tôi, điều quan trọng là phải có một thỏa thuận chính thức về giao diện giữa các đối tác kinh doanh. Ngay cả khi những gì được thông qua là hiển nhiên, nó sẽ giúp xác định ai phải sửa những gì sau đó nếu ai đó thay đổi giao diện trước đó.

Định dạng dữ liệu cũng là một phần của giao diện giống như tên động từ.

WADL thu hút những người đến từ thế giới SOAP nơi người ta thường sử dụng trình tạo mã để tạo mã phía máy khách dựa trên WSDL. Tôi không nghĩ rằng cơ chế đó hữu ích trong REST vì nó tạo ra mã máy khách được kết hợp với các điểm cuối của máy chủ.

Tôi tin rằng nếu bạn xác định đúng các loại phương tiện của mình và sử dụng siêu phương tiện trong các loại phương tiện đó, thì không cần thiết phải có WADL. Mô tả về các điểm cuối có sẵn được chứa trong chính các định nghĩa loại phương tiện. Và nếu bây giờ bạn đang nói với chính mình, nhưng ứng dụng / xml không chứa bất kỳ thông tin nào về các siêu liên kết có sẵn, thì tôi nói BINGO. Đó là lý do tại sao tôi không nghĩ application / xml và application / json là các loại phương tiện thích hợp cho REST. Tôi không nói rằng đừng sử dụng XML hoặc JSON, chỉ là đừng sử dụng tên loại phương tiện chung chung.

Lời kêu gọi khác của WADL là nhằm mục đích ghi lại các dịch vụ REST. Thật không may, nó dẫn các nhà phát triển đi sai đường khi WADL cố gắng ghi lại các điểm cuối phía máy chủ. Việc ghi lại các dịch vụ REST nên tập trung chủ yếu vào các loại phương tiện. Một nhà phát triển máy khách sẽ có thể viết một máy khách REST mà không cần biết bất kỳ url nào ngoài url gốc.

WADL cho phép bạn tạo mã, kiểm tra và tài liệu. Trên thực tế, có rất ít công cụ rất hữu ích sử dụng WADL, bạn có thể xem một số ví dụ tại đây . Vấn đề với REST "thuần túy", như được mô tả trong luận văn của Fielding, là viết ứng dụng khách hỗ trợ Hypermedia (ví dụ như viết ứng dụng khách dựa trên Java Swing). Với WADL, nhiệm vụ này hoàn toàn tự động, và đó là một lợi thế rất lớn theo quan điểm của tôi. Kiểm tra cũng trở nên dễ dàng hơn.

Trước khi đưa ra lời giải thích của mình, hãy để tôi nói rằng hầu hết những kẻ cực đoan REST thuần túy sẽ bắt nguồn từ đó đến tận cùng trái đất. Tôi không đồng ý với họ, vì tôi muốn hoàn thành một việc gì đó, nhưng mong bạn biết đấy.

WADL là một mô tả của một API dịch vụ web, giống như WSDL dành cho các dịch vụ web loại SOAP, được thiết kế để phù hợp hơn với các giao diện RESTful (một thứ mà WSDL còn kém).

Theo kinh nghiệm của tôi, cách sử dụng chính của nó là cho phép bạn tạo mã khách hàng có thể gọi dịch vụ (hữu ích nếu đó là một API rất lớn, theo nghĩa đen, điều này tiết kiệm hàng giờ làm việc). Nó cũng phục vụ mục đích ghi lại giao diện giống REST.

REST không chỉ định gì về WADL.

Khi bạn muốn hiển thị các dịch vụ REST, cách tốt nhất là tạo WADL và chia sẻ với người tiêu dùng (tương tự như WSDL trong các dịch vụ web dựa trên SOAP) .WADL được sử dụng để mô tả dịch vụ tại chỗ.

WADL không cần thiết để sử dụng. Tuy nhiên, nếu bạn đang làm việc với ứng dụng phức tạp hiện có và bạn muốn thực hiện lệnh gọi dịch vụ REST bằng cách thay thế lệnh gọi dịch vụ EJB / SOAP, thì bạn nên sử dụng WADL. Bằng cách sử dụng WADL tạo sơ khai java phía máy khách, bạn sẽ được đồng bộ hóa với dịch vụ.

Bạn có thể tạo sơ khai java phía máy khách bằng cách sử dụng tệp WADL với sự trợ giúp của plugin wadl2java maven.