Такие системы существуют, и я являюсь автором одного из них. Он называется Piqi-RPC, и он проверяет входные и выходные параметры на основе IDL для API-интерфейсов RPC через HTTP.
Он поддерживает JSON, XML и протоколы Google Protocol в качестве форматов представления данных для ввода и вывода запросов HTTP POST. Клиенты могут выбрать любой из трех форматов и указать свой выбор, используя стандартные заголовки HTTP Accept и Content-Type.
Итак, да, в теории, вы смотрите в правильном направлении. Однако на данный момент Piqi-RPC поддерживает записи серверов только в Erlang, и это будет не очень полезно для вас, если вы используете другой стек. Я слышал, что Apache Thrift также поддерживает JSON через HTTP-транспорт, но я не проверял. Другой вид подобной системы, которую я знаю (также для Erlang), называется UBF. Я слышал о библиотеках для Java, которые могут анализировать и проверять JSON на основе спецификации буферов протокола (например, http://code.google.com/p/protostuff/).
Сама идея сама по себе далека от новизны, но на практике ее мало. Это сложная проблема.
Исторически, IDL использовались для определения интерфейса и сериализации двоичных данных и не столько для проверки динамических форматов обмена данными (например, XML и JSON), которые возникли позже. Sun-RPC IDL и CORBA IDL относятся к первой категории. WSDL будет одним из немногих примеров, охватывающих обе области, но это ужасная технология, и это будет плохой выбор для большинства современных систем. Кроме того, существует много языков схем (также известных как DDL - языки определения данных), большинство из которых являются высокоспециализированными и работают только с одним форматом представления, например. XML или JSON. Немногие из них имеют стабильные реализации.
Piqi project и Piqi-RPC, которая основана на нем, построены вокруг несколько довольно простых реализаций:
DLL не должен быть явно привязан к какому-либо конкретному формату представление данных или построен вокруг Это. Вместо этого такой язык может быть довольно универсальным и охватывать широкий спектр практических случаев использования (например, сериализация данных на разных языках и проверка данных) и форматы данных (например, JSON, XML, протокольные буферы).
IDL для связи в стиле RPC может быть реализована как тонкий, в основном синтаксический слой поверх универсального DDL.
Такие IDL и спецификации интерфейса могут быть транспортными агностиками.
Говоря о API-интерфейсах типа REST по HTTP по сравнению с API-интерфейсами RPC через HTTP.
С API-интерфейсом в стиле RPC разработчик сервиса или автоматическая система должны проверить три вещи: имя функции (согласно некоторой схеме присвоения имен), ввод и, если вы выберете так, вывод.
В случае API-интерфейсов REST люди попадают в беду без уважительной причины. Теперь у них есть и еще материал для проверки: произвольно сложный синтаксис URL, включая динамические параметры, закодированные в сегментах URL (для всех методов HTTP) и строку запроса URL (только для метода HTTP GET), соответствие HTTP-методам (должно ли оно быть GET, POST, PUT, DELETE и т. д.), Тело HTTP, когда некоторые параметры идут туда (иногда они делают это вручную дважды для параметров, представленных в JSON и XML), пользовательских заголовков HTTP и отдельно - служебную документацию. Представьте, что IDL поддерживает все это!
Если вам действительно нужно использовать существующее решение, я бы просто пошел с json-схемой, которая кажется достаточно простой в использовании. В противном случае, я не думаю, что слишком сложно проверить структуру JSON - убедитесь, что у каждого объекта есть нужные вам свойства, и делайте это рекурсивно, если вы тоже. В отличие от XML, JSON довольно прост в проверке, поэтому может возникнуть проблема правильного решения проверки схемы. –