- PVSM.RU - https://www.pvsm.ru -
Во многих компаниях, как и моей, есть много проектов и продуктов. И у продуктов бывают веб-интерфейсы, чтобы этими продуктами как-то манипулировать. В нашем случае это простенькие RESTful веб-сервисы, а поверх них ещё более простенькие веб-странички с формочками и кнопочками. Все эти веб-странички до того похожи друг на друга, что возникла мысль написать унифицированный продукт, который бы спрашивал сервер о поддерживаемых сервисах, и получал бы полное описание параметров к этим сервисам, так чтобы можно было нарисовать те самые простенькие формочки. То есть, веб-сервисы должны описывать себя, достаточно исчерпывающе, чтобы наш клиент мог построить GUI для них, и ничего не надо было бы делать руками. Как раз такая картинка гуглится по запросу «REST»:
Сходу нашлась такая технология, как WADL [1] — Web Application Description Language. Но это XML, с ним не хотелось возиться в javascript, python и perl. Был выбран его более легковесный JSON-аналог — JSDL [2] — JSON Service Description Language.
Оказалось, что в JSDL (как и в WADL) не помещается вся информация, нужная для формирования полноценных формочек, и ряд дополнительных соглашений с веб-сервисами должны быть установлены:
GET /service_groups
и получает JSON вида
[
{
"description": "Manipulate resource1",
"services": ["resource1"]
},
{
"description": "Manipulate resource2 and its statistics",
"services": ["resource2", "resource2_stat"]
}
]
GET /jsdls
. Получаем JSON вида
[["resource1", {...object...}], ["resource2", {...object...}], ["resource2_stat", {...object...}]]
где object
— JSDL-описание сервиса (операции, их параметры и т.д.).
Allow: HEAD,GET,PUT,POST,DELETE,OPTIONS
Access-Control-Allow-Origin: *
Access-Control-Allow-Headers: content-type,X-Requested-With
Access-Control-Allow-Methods: HEAD,GET,PUT,POST,DELETE,OPTIONS
Наш клиент валидирует пришедшие от сервера JSON-объекты в соответствии со схемой JSDL, описанной с помощью JSON Schema [6]. Мы просто взяли JSDL-схему [7], метасхему JSONa [8], и первый валидатор из предложенных на сайте, вот этот [9]. Метасхема нужна, так как параметр в JSDL является схемой и описывается метасхемой, которую мы немного расширили, как указано ниже. Надеюсь, понятно (мне лично не всегда).
К сожалению, средствами стандартного JSDL всё равно не получается полностью выразить наши формочки.
Схеме параметра не хватало следующих выразительных средств:
api.com/resource1/paramvalue1/paramvalue2
api.com/resource1?param1=value1¶m2=value2
Для решения этих проблем схему JSDL-описания параметра (ту самую метасхему) пришлось расширить следующим образом:
//добавим атрибут name
ParamJSONSchema["properties"]["name"] = {
"type": "string"
}
//добавим атрибут passing - как передавать значение
ParamJSONSchema["properties"]["passing"] = {
"type": "string",
"default": "keyvalue",
"enum": ["keyvalue", "positional", "raw"]
}
//добавим в типы параметра multistring для случая textarea
ParamJSONSchema["definitions"]["simpleTypes"]["enum"].push("multistring");
Теперь есть все данные, чтобы нарисовать формочку для запроса и правильно отправить её содержимое сервису. Результат выводим на страничку.
Сам проект лежит на гитхабе [10] и может быть использован для реализации единого веб-интерфейса к сервисам в вашей компании, например.
Автор:
Источник [11]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/javascript/63956
Ссылки в тексте:
[1] WADL: http://www.w3.org/Submission/wadl/
[2] JSDL: http://jsdl.codeplex.com/
[3] безопасностью: http://en.wikipedia.org/wiki/Same-origin_policy
[4] JSONP: http://en.wikipedia.org/wiki/JSONP
[5] RFC: http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
[6] JSON Schema: http://json-schema.org/
[7] JSDL-схему: https://jsdl.svn.codeplex.com/svn/-%20Specification/Specification.json
[8] метасхему JSONa: http://json-schema.org/draft-04/schema
[9] вот этот: http://geraintluff.github.io/tv4/
[10] на гитхабе: https://github.com/nifigase/restgui
[11] Источник: http://habrahabr.ru/post/228457/
Нажмите здесь для печати.