Я планирую веб-сервис XML, который принимает запрос XML и возвращает ответ XML через HTTP. Это не SOAP и не просто REST - думаю, его лучше всего описать как API POX (Plain Old XML). (Более подробно в конце этого поста, если вам интересно, но я стараюсь, чтобы мой основной вопрос был общим.)
Мой опыт работы с XML включает в себя немного больше, чем DOM и SAX ... Я не очень разбираюсь в том, какие именно наборы инструментов обычно используют разработчики для интеграции своих приложений со сторонними веб-сервисами. Но я хочу сделать этот веб-сервис максимально простым для использования другими.
Я создал схему XML для описания того, что разрешено в запросе XML и ответе XML. Достаточно просто, за исключением того, что я не знаю, насколько хорошо он будет работать с различными наборами инструментов. Я понимаю, что существуют наборы инструментов, которые могут взять схему XML и превратить ее в классы (например, для .Net или Java). Многие потенциальные клиенты, с которыми я говорил, используют .Net в той или иной форме, поэтому я полагаю, что наборы инструментов .Net наиболее актуальны в этом случае. (Хотя я определенно не хочу делать что-то конкретное .Net, я хочу попытаться сделать этот веб-сервис максимально простым для обычного клиента.)
В частности, мне интересно, что мне следует сделать, чтобы упростить разработку для разработчиков:
- Должен ли я иметь XSD-файл для запроса и один для ответа или объединить их в один XSD-файл? Или я должен разделить его, скажем, на 3 XSD-файла: один для материала, специфичного для запроса, один для материала, специфичного для ответа, и один для общих типов?
- Если атрибут может быть числом, скажем, от -100 до +100, я могу и буду ограничивать его в XSD, используя minInclusive и maxInclusive, но я должен определить его как байт или целое число или что ( см. Типы здесь )? Байт достаточно большой, но у меня есть необоснованное ощущение, что байт может плохо работать с наборами инструментов. Или, возможно, это может вызвать проблемы, если позже я решу изменить его на короткое и расширить пределы, скажем, до -200 и + 200.
- Существуют ли какие-либо конкретные конструкции XSD, которые, как известно, вызывают проблемы с наборами инструментов, и которых следует избегать, если это возможно?
- Это действительно хорошая идея - вообще предоставить XSD? Будет ли это на самом деле облегчить жизнь людям? (Я полагаю, что будет, но лучше проверить!)
- Позже я мог бы захотеть обновить XSD, чтобы ввести некоторые новые опции. Я полагаю, что могу сделать это осторожно, чтобы XML, который был совместим со старой версией, оставался совместимым с новой версией. Но разве это полностью испортит жизнь разработчикам, которые использовали наборы инструментов и автоматически сгенерированный код?
- Есть ли что-то, в частности, что я должен знать? Или я в первую очередь задаю все неправильные вопросы ?! : D
Немного больше информации о том, что я пытаюсь сделать (только если вы этого хотите):
Я пытался держать мой главный вопрос в общих чертах, чтобы другие могли найти его полезным, но, в случае его актуальности, вот немного больше информации о том, чего я пытаюсь достичь и что я планирую.
Я разрабатываю веб-сервис, который будет рассчитывать данные по запросу только для авторизованных клиентов. Запрос клиента будет состоять из спецификации XML данных, которые они хотят, наряду с аутентификацией. Мои серверы рассчитают запрошенные данные и отправят их в виде XML-ответа.
Я никогда раньше не создавал веб-службы, но я потратил довольно много времени на изучение SOAP, REST, схемы XML, безопасности и ряда существующих веб-служб / API, таких как Amazon SimpleDB Flickr и Netflix .
После долгих размышлений я решил, что:
- SOAP не подходит для этого, потому что многие клиенты будут небольшими настольными приложениями, а не крупными корпоративными приложениями с наборами инструментов для таких вещей, как XML-подписи. Кроме того, для меня это звучит так, как будто SOAP может стать кошмаром для взаимодействия. Возможно, я добавлю опцию SOAP позже, но в идеале я бы вообще ее избегал.
- XML имеет больше смысла, чем JSON, потому что клиенты этого веб-сервиса более знакомы с XML, и я не могу вспомнить вариант использования, который включал бы клиент JavaScript, использующий веб-сервис, так что очевидное преимущество JSON отсутствует. t релевантно.
- REST в чистом виде не подходит для этого, потому что этот веб-сервис будет более ориентирован на активность, чем на ресурс ( эта статья помогла мне увидеть это различие). К ужасу любого пуриста REST, для удобства я мог бы назвать его «API REST», но на самом деле я думаю, что его лучше всего описать как API POX (Plain Old XML API). Я стараюсь не слишком фокусироваться на терминологии.
- Будет запрос XML и ответ XML.
- В целях безопасности я буду использовать систему, основанную на Amazon SimpleDB и OAuth . В основном я планирую принять запрос XML, преобразовать его в байтовый массив, создать сигнатуру / MAC с использованием HMAC-SHA1 или аналогичного и отправить байтовый массив XML и байтовый массив сигнатуры / MAC в качестве параметров HTTP POST, Base- 64 закодировано. Это еще не все (открытые ключи, закрытые ключи, временные метки и одноразовые номера), но в этом суть.
Я разработал XML-схему для запроса и ответа, в настоящее время все только в одном файле .xsd, но мне интересно, как лучше структурировать вещи для совместимости и простоты использования из различных платформ / наборов инструментов и т. Д.