Разработайте веб-сервис XML и XML-схему для совместимости с различными инструментариями

Я планирую веб-сервис XML, который берет запрос XML и возвращает ответ XML по HTTP. Это не SOAP, и это не чистый REST ни один - я думаю, что это могло бы быть лучше всего описано как POX (Простой XML) API. (Больше деталей к концу этого сообщения, если Вам интересно, но я пытаюсь сохранить свой основной вопрос общим.)

Мой опыт с XML включает немного больше, чем DOM и SAX... У меня нет большой части подсказки о видах инструментариев, которые разработчики обычно используют для интегрирования их приложений со сторонними веб-сервисами. Но я хочу сделать этот веб-сервис максимально простым, чтобы другие использовали.

Я сделал XML-схему для описания то, что позволяется в запросе XML и ответе XML. Достаточно простой, кроме я не знаю, как хорошо это будет работать с различными инструментариями. Я понимаю, что существуют инструментарии там, которые могут взять XML-схему и превратить ее в классы (например, для .NET или Java). Много потенциальных клиентов, с которыми я говорил, использует .NET в некоторой форме или форме, таким образом, я предполагаю, что инструментарии .NET являются самыми релевантными в этом экземпляре. (Хотя я определенно не хочу делать что-то .NET конкретный, я действительно хочу попытаться сделать его максимально легким, чтобы типичный клиент использовал этот веб-сервис.)

Так конкретно я задаюсь вопросом о том, что я должен сделать для создания вещей легче для разработчиков:

1. Я должен иметь файл XSD для запроса, и один для ответа, или поместить их обоих вместе в один файл XSD? Или если я разделил его на, скажем, 3 файла XSD: один для определенного для запроса материала, один для определенного для ответа материала, и один для общих типов?
2. Если атрибут может быть числом между, скажем,-100 и +100, я, и будет, может ограничить его в XSD с помощью minInclusive и maxInclusive, но я должен определить его как байт или целое число или что (см. типы здесь)? Байт является достаточно большим, но у меня есть необоснованное чувство, что байт не мог бы играть хорошо с инструментариями. Или возможно это могло бы вызвать проблемы, если я позже решаю изменить его на короткое и развернуть пределы, скажем,-200 и +200.
3. Есть ли какие-либо конкретные конструкции XSD, которые, как известно, вызывают проблемы с инструментариями, и что я должен избежать если возможный?
4. Это - на самом деле хорошая идея обеспечить XSD вообще? Это на самом деле сделает вещи легче для людей? (Я полагаю, что это было бы, но лучше всего проверять!)
5. Позднее я мог бы хотеть обновить XSD для представления некоторых новых опций. Я полагаю, что могу сделать это тщательно таким образом, что XML, который был совместим со старой версией, останется совместимым с новой версией. Но это полностью завинтит вещи для разработчиков, которые использовали инструментарии и автоматически сгенерировали код?
6. Есть ли что-либо еще в особенности, что я должен знать? Или я задаю все неправильные вопросы во-первых?!:D

Немного больше информации о том, что я пытаюсь сделать (только если Вы хотите ее):

Я пытался сохранить свой основной вопрос общим, так, чтобы другие нашли это полезным, но, в случае, если это релевантно, вот немного больше информации о том, чего я пытаюсь достигнуть, и что я планирую.

Я разрабатываю веб-сервис, который вычислит данные по требованию для авторизованных клиентов только. Клиентский запрос будет состоять из спецификации XML данных, которые они хотят, наряду с аутентификацией. Мои серверы вычислят данные, которые они попросили, и отправьте их как ответ XML.

Я никогда не создавал веб-сервис прежде, но я провел долгое время, изучая SOAP, REST, XML-схему, безопасность и много существующих веб-сервисов/API как Amazon SimpleDB, Flickr и Netflix.

После большого обдумывания я решил что:

1. SOAP не является правильным для этого, потому что многие клиенты будут маленькими настольными приложениями, не приложениями крупного предприятия с инструментариями для материала как XML-подписи. Плюс он звуки мне как SOAP могли бы быть кошмаром совместимости. Возможно, я добавлю опцию SOAP позже, но идеально я избежал бы его в целом.
2. XML имеет больше смысла, чем JSON, потому что покупатели этого веб-сервиса более знакомы с XML, и я не могу думать о варианте использования, который вовлек бы клиент JavaScript, использующий веб-сервис, так, чтобы очевидное преимущество JSON не было релевантно.
3. REST в его самом чистом смысле не является правильным для этого, потому что этот веб-сервис будет большим количеством действия, ориентированного, чем ориентированный ресурс (эта статья помогла мне видеть это различие). К тревоге любых пуристов REST я мог бы назвать это "API REST" для удобства, но действительно я думаю, что это могло бы быть лучше всего описано как API POX (Простой API XML). Я пытаюсь не сфокусироваться слишком много на терминологии.
4. Будет запрос XML и ответ XML.
5. Для безопасности я буду использовать систему, вдохновленную Amazon SimpleDB и OAuth. В основном я планирую взять запрос XML, преобразовать его в массив байтов, создать подпись/MAC с помощью HMAC-SHA1 или подобный, и отправить массив байтов XML и массив байтов подписи/MAC как HTTP параметры POST, Основа 64 закодированных. Существует больше к нему, чем тот (открытые ключи, закрытые ключи, метки времени и данные случаи), но это - суть его.

Я разработал XML-схему для запроса и ответа, в настоящее время все только в одном .xsd файле, но я задаюсь вопросом о том, как лучше всего структурировать вещи для совместимости и простоты использования с различных платформ/инструментариев и т.д.