2009-09-24 40 views
9

Đây là câu hỏi nhiều phần. Tôi vừa xem một bài thuyết trình rất thú vị về YQL của nhà phát triển chính (tốt nghiệp chương trình MS của tôi). Trong khi nó rất hấp dẫn, và tôi mong muốn thử nó, tôi tự hỏi nếu có ai biết về các khung thay thế để truy vấn nhiều API dịch vụ web để làm cho chúng xuất hiện liền mạch, mục đích rõ ràng của YQL?Lựa chọn thay thế cho YQL

Chiến lược của Yahoo là tạo các định nghĩa lược đồ XML ràng buộc các tham số của dịch vụ web đã cho vào các tham số truy vấn Bảng mở YQL của chúng, mà tôi nghĩ là rất thông minh. Có bất kỳ công cụ nào cố gắng (có lẽ tôi ngây thơ ở đây) để tự động hoá việc phát hiện các tham số trong nói một API REST? Tôi biết rằng với các API SOAP, bởi vì có một WSDL được công bố, nó làm cho tự động hóa dễ dàng hơn, nhưng vẫn chưa có cách nào để làm điều này với REST? Có ai đang cố gắng không?

+0

Tôi rất hoài nghi rằng một công cụ tự động phát hiện tồn tại cho REST API vì cùng một thực thể có thể có nhiều biểu diễn khác nhau. Và có thể xác định ad-hoc tham số nào nó chấp nhận. WADL cố gắng để làm cho mọi thứ tốt hơn, nhưng tôi nghĩ nó đã chết trong nước vì nó đi ngược lại bộ óc tối giản của các nhà phát triển REST. Câu hỏi hay.+1 –

Trả lời

5

Có người đang cố gắng tạo ngôn ngữ mô tả cho REST. Nỗ lực phổ biến nhất là WADL. Có rất nhiều câu hỏi về WADL ở đây trên SO. Nó là một ý tưởng tốt? Theo tôi thì không.

REST không cần một mô hình khám phá vượt quá những gì nó đã có với hypermedia, bởi vì đang cố gắng giải quyết vấn đề ở một tầng kiến ​​trúc khác với dịch vụ web. Các dịch vụ Web cung cấp dữ liệu đến mô hình logic/miền kinh doanh của ứng dụng. REST là về việc cung cấp nội dung và hành vi cho một lớp trình bày.

Tương tự như thế nào? Hãy nghĩ về sự khác nhau giữa một đối tượng và cấu trúc trong C++. Cấu trúc chỉ là dữ liệu đơn giản mà một số quy trình khách hàng sẽ thao tác. Đó là những gì một dịch vụ web làm, nó trả về một đoạn dữ liệu, một cấu trúc. Chắc chắn có thể nó đã thực hiện một loạt các xử lý phía máy chủ để tạo ra kết quả, nhưng kết quả cuối cùng là một khối dữ liệu. Một giao diện REST cung cấp một đối tượng. tức là Nó chứa cả dữ liệu và các phương thức có thể được sử dụng để thao tác đối tượng đó. Theo định nghĩa, nếu bạn hiểu giao diện đồng nhất và bạn hiểu loại phương tiện được trả lại, bạn đã biết bạn có thể làm gì với phản hồi. Cơ chế khám phá là không cần thiết.

Nếu bạn thấy khó tin, suy nghĩ về web. Trình duyệt web khám phá các trang web như thế nào? Web không có cơ chế khám phá được chính thức hóa, nhưng vẫn có một thế giới thông tin mà chúng ta có thể khám phá bằng trình duyệt web.

+0

Tôi không đồng ý với câu trả lời này, tôi không nghĩ rằng REST chỉ giới hạn việc cung cấp nội dung (và hành vi) cho một "lớp trình bày". Và tôi coi hành vi ràng buộc hành vi xấu đối với REST. – ElLocoCocoLoco

+0

@ElLocoCocoLoco Nếu bạn sẽ giúp tôi hiểu ràng buộc nào của REST bị vi phạm bởi "hành vi ràng buộc với REST" và tác động tiêu cực của các vi phạm đó thì có thể tôi sẽ hiểu tại sao bạn coi đó là "hành vi xấu". –

+0

Bạn có hiểu tiếng Pháp không? https://fr.wikipedia.org/wiki/Representational_State_Transfer Trong việc phân phối "hành vi", tôi giả sử bạn đang nói về thứ 6 (tùy chọn ràng buộc) Mã-Theo-Nhu cầu của các dịch vụ REST. Nếu đó là trường hợp thì đó thường được coi là một thực tế xấu bởi vì "một nhà nước trở nên phụ thuộc vào khách hàng và không phải là máy chủ mâu thuẫn với Quy tắc 2." Nếu bạn đang nói về điểm 4.3 "phản ứng giải thích bản chất của họ" ngay cả trong trường hợp này, chúng tôi cần một số dịch vụ để giải thích bản chất của kết quả trước khi tự thực hiện yêu cầu (Adaptative/Auto discovery Systems) – ElLocoCocoLoco

1

Có trang web nhỏ này http://zachgrav.es/yql/tablesaw/ thực sự tự động phát hiện thông số trong api REST và biến nó thành bảng tương thích YQL.

1

Có hai cách để tìm thông tin. Hoặc bạn sử dụng một ngôn ngữ rõ ràng 100% hoặc bạn sử dụng một ngôn ngữ tự nhiên. Bất cứ điều gì ở giữa như YQL là cam chịu thất bại bởi vì nó cung cấp không và hoạt động tốt chỉ với các ví dụ tác giả của nó chào hàng.

Tôi đã viết blog về điều này tại http://zscraper.wordpress.com/2012/05/30/enough-with-crawling-2. Lập trường cá nhân của tôi là bạn sẽ luôn nhận được kết quả chính xác nhất nếu bạn làm bài tập ở nhà trước, tức là nghiên cứu miền mục tiêu và tìm hiểu cách truy vấn nó một cách rõ ràng.

Để trả lời câu hỏi của bạn và cung cấp cho bạn một giải pháp thay thế - hãy thử Bobik. Đây là dịch vụ cạo được hỗ trợ bởi đám mây mà bạn kiểm soát thông qua REST API. Soạn "truy vấn" của bạn theo cú pháp truyền thống (Bobik hỗ trợ Javascript, JQuery, XPATH và CSS) và gọi Bobik để chạy chúng từ bất kỳ môi trường phía máy khách nào (trang web, ứng dụng dành cho thiết bị di động hoặc máy chủ của bạn).

Hy vọng điều này sẽ hữu ích.

+3

Trang web, http://usebobik.com, không còn tồn tại. Tôi cũng tin rằng dịch vụ không còn nữa. – Ragaar