У меня здесь нет проблемы с генерацией кода.
REST редко требует какой-либо генерации кода. Это просто HTTP-запросы с простыми полезными нагрузками JSON (или XML).
Вы используете существующие библиотеки HTTP (например, Apache Commons или Python urrlib2). Вы используете существующие библиотеки JSON (или XML). (например, проект Джерси имеет хорошее преобразование JAXB-JSON).
Что "генерируется"? Наша библиотека RESTful на Java и Python практически идентична и просто делает запросы REST через библиотеку HTTP.
class OurService {
def getAResource( String argValue ) {
path = { "fixed", argValue };
URI uri= build_path( path );
return connection.get( uri )
[Я исключил обработку исключений.]
Вы пытаетесь наложить слой на сложное разделение интерфейса / реализации SOAP?
Клиент "написанный на JAVA, использующий веб-сервис RESTful" ... "Инструмент Perl, выполняющий ту же самую работу" ... "в C ++, Python и C #".
Correct.
"где код не может быть передан"
Правильно. Код не может быть передан. Вы должны написать каждому клиенту на соответствующем языке. Написание своего рода «генератора» для создания этого кода из WSDL - это (1) огромный объем работы и (2) ненужная. Каждый язык имеет уникальный синтаксис и уникальные библиотеки для выполнения запросов REST. Но он настолько прост и универсален, что там почти ничего нет.
Канонический пример в Python:
class Some_REST_Stub( object ):
def get_some_resource( self, arg ): # This name is from the WSDL
uri = "http://host:port/path/to/resource/%s/" % arg # This path is from the WSDL
data= urllib2.open( uri )
return json.load( data )
Этот блок кода на короче , чем WSDL, необходимый для его описания. И кажется, что это легче изменить, потому что имя - это имя метода, а URI - просто строка.
В большинстве языков клиент примерно такой простой. Я только что написал кучу клиентского кода REST на Java. Это более многословно, но это общий материал. Создайте запрос, проанализируйте JSON, который возвращается. Вот и все.
Объявление RESTful WSDL скрывает две части тривиальной информации в большом количестве XML.
Предоставляет «имя интерфейса» для URI.
Он документирует значение GET, PUT, POST и DELETE, предоставляя имена методов класса-заглушки.
Это не поможет вам написать много кода, так как не так много кода. Обратите внимание, что все запросы REST имеют одинаковую общую структуру HttpRequest и HttpResponse. Запрос содержит общие сущности. Ответ также содержит универсальный объект, который необходимо проанализировать. Там очень мало для отдыха - суть в том, чтобы быть максимально простым.
Это в значительной степени устраняет необходимость в WSDL, поскольку все является универсальным JSONObject или XML URLE, закодированным и отправленным в виде строки.
«Я бы скорее вызвал функцию класса, которая возвращает мои данные, инкапсулированные в объект, вместо того, чтобы беспокоиться об URL, аргументах, ответе и т. Д.»
Правильно, вам нужно написать класс-заглушку. У него почти нет кода, и он будет короче, чем требуется WSDL для его описания.
«Умножьте это на каждый инструмент, и теперь, когда я внесу изменение в службу, я должен обновить URL-адреса в каждой операции CRUD и все, что с этим связано».
Вы можете обновить класс заглушки на каждом языке для каждого клиента. Или вы можете обновить WSDL и затем заново создать каждого клиента. Это похоже на тот же объем работы, поскольку URI тривиально инкапсулируется в клиентском коде.
«Думаю, я представляю, что с WSDL это тот аспект, который сделан для вас».
Мне неясно, что "сделано". Переводить многословный и сложный WSDL в простой класс заглушки? Я полагаю, это может быть полезно. За исключением того, что WSDL больше, чем класс заглушки. Я предполагаю, что вам, вероятно, будет проще написать класс-заглушку. Это короче, чем WSDL.
«Ваш код просто взаимодействует с заглушками».
Правильно.
"Что делают заглушки, кого это волнует? URL, аргументы, ответы - если что-то изменится, просто создайте заглушки из WSDL."
К сожалению, почти ничего из этого не требует реального программирования. Генерировать его из WSDL - больше работы, чем просто писать. URI это строки. Аргументы являются общими JSONObjects. Ответы являются общими HttpResponses, включая JSONArray. Вот и все.
«Мне также не пришлось обновлять весь код, касающийся специфики создания запроса и обработки ответа.»
За исключением каких-либо интересных особенностей создания запроса. HTTP простой, общий материал. GET, POST, PUT и DELETE - все почти идентичны.