Hệ thống như vậy tồn tại và tôi là tác giả của một trong số chúng. Nó được gọi là Piqi-RPC và xác thực dựa trên IDL của các tham số đầu vào và đầu ra cho các API kiểu RPC qua HTTP.
Nó hỗ trợ JSON, XML và Google Protocol Buffers làm định dạng biểu diễn dữ liệu cho đầu vào và đầu ra của các yêu cầu HTTP POST. Khách hàng có thể chọn sử dụng bất kỳ định dạng nào trong số ba định dạng này và chỉ định lựa chọn của họ bằng cách sử dụng tiêu đề HTTP tiêu chuẩn Accept và Content-Type HTTP.
Vì vậy, vâng, theo lý thuyết, bạn đang tìm đúng hướng. Tuy nhiên, tại thời điểm này, Piqi-RPC chỉ hỗ trợ viết các máy chủ trong Erlang và nó sẽ không hữu ích cho bạn nếu bạn sử dụng một ngăn xếp khác. Tôi nghe nói rằng Apache tiết kiệm cũng hỗ trợ JSON qua giao thông HTTP, nhưng tôi đã không kiểm tra. Một loại hệ thống tương tự mà tôi biết (cũng cho Erlang) được gọi là UBF. Tôi đã nghe nói về các thư viện cho Java có thể phân tích và xác thực JSON dựa trên đặc điểm kỹ thuật của Protocol Buffers (ví dụ: http://code.google.com/p/protostuff/).
Ý tưởng bản thân không xa mới, nhưng không có nhiều hệ thống tiếp cận nó trong thực tế. Đây là một vấn đề khó khăn.
Trước đây, IDL được sử dụng để định nghĩa giao diện và tuần tự hóa dữ liệu nhị phân và không quá nhiều để xác thực định dạng trao đổi dữ liệu động (ví dụ: XML và JSON). Sun-RPC IDL và Corba IDL nằm trong danh mục đầu tiên. WSDL sẽ là một trong số ít ví dụ bao gồm cả hai lĩnh vực, nhưng nó là một công nghệ khủng khiếp và nó sẽ là một lựa chọn tồi cho hầu hết các hệ thống hiện đại. Ngoài ra, có nhiều ngôn ngữ lược đồ (còn được gọi là DDLs - ngôn ngữ định nghĩa dữ liệu), hầu hết trong số đó đều có tính chuyên môn cao và chỉ hoạt động với một định dạng biểu diễn, ví dụ: Lược đồ XML hoặc JSON. Rất ít trong số đó có triển khai ổn định.
Các Piqi-RPC Piqi project và, mà là dựa vào nó, được xây dựng xung quanh một vài ngộ khá đơn giản:
DLL không nhất thiết phải được gắn một cách rõ ràng với bất kỳ định dạng biểu diễn dữ liệu cụ thể hoặc xây dựng xung quanh nó. Thay vào đó, ngôn ngữ đó có thể khá phổ biến và bao gồm nhiều trường hợp sử dụng thực tế (ví dụ: tuần tự hóa dữ liệu chéo và xác thực dữ liệu) và định dạng dữ liệu (ví dụ: JSON, XML, Bộ đệm giao thức).
IDL cho giao tiếp kiểu RPC có thể được triển khai dưới dạng lớp mỏng, chủ yếu là cú pháp trên đầu DDL phổ quát.
IDL và thông số giao diện như vậy có thể vận chuyển bất khả tri.
Phát biểu của API kiểu REST qua HTTP so với API kiểu RPC qua HTTP.
Với API kiểu RPC, nhà phát triển dịch vụ hoặc hệ thống tự động phải xác thực ba điều: tên hàm (theo một sơ đồ đặt tên dịch vụ), đầu vào và, nếu bạn chọn, đầu ra.
Trong trường hợp API kiểu REST, mọi người gặp rắc rối vì không có lý do chính đáng. Bây giờ, họ có thêm nhiều thứ hơn để xác thực: cú pháp URL phức tạp tùy ý, bao gồm các thông số động được mã hóa trong phân đoạn URL (cho tất cả phương thức HTTP) và chuỗi truy vấn URL (chỉ cho phương thức HTTP GET), tương ứng với phương thức HTTP GET, POST, PUT, DELETE, v.v.), HTTP body khi một số tham số xuất hiện (đôi khi chúng thực hiện thủ công hai lần đối với các tham số được biểu diễn bằng JSON và XML), tiêu đề HTTP tùy chỉnh và tài liệu dịch vụ riêng biệt. Hãy tưởng tượng một IDL hỗ trợ tất cả những điều đó!
Nếu bạn thực sự cần sử dụng giải pháp hiện có, tôi sẽ chỉ sử dụng lược đồ json, có vẻ dễ sử dụng. Nếu không, tôi không nghĩ rằng quá khó để tự kiểm tra cấu trúc JSON - hãy kiểm tra xem mỗi đối tượng có thuộc tính bạn cần hay không và thực hiện điều đó một cách đệ quy nếu bạn có. Không giống như XML, JSON khá đơn giản để xác thực, đó có thể là lý do tại sao không có giải pháp xác thực hợp lệ lược đồ nào tồn tại. –