УСПОКОИТЕЛЬНЫЕ веб-сервисы: попытка достигнуть HATEOAS с пользовательским XML
Koogra является компонентом с открытым исходным кодом, записанным в C#, который читает и пишет файлы Excel.
3 ответа
То, что вы делаете, возвращая URL-адрес в resulturi, уже фактически является гипермедиа. Единственная проблема заключается в том, что вам нужен медиа-тип, который сообщает клиенту, как форматируется ответ, чтобы он мог анализировать URL-адреса предсказуемым и документированным способом.
Вариант 1: Создайте свой собственный тип мультимедиа, например vnd.yourcompany.Resource + xml. Делая это, вы заявляете, что тип мультимедиа может быть проанализирован синтаксическим анализатором xml, но он следует некоторым особым правилам, которые определены вашей компанией. На этом этапе вы можете использовать любой стандарт, который хотите для определения гипермедийных ссылок (см. этот вопрос). Одним из приятных преимуществ этого является то, что если через 6 месяцев вы решите, что вам нужно внести критические изменения в формат вашего XML, вы можете создать vnd.yourcompany.ResourceV2 + xml, и если вы достаточно умны, чтобы использовать accept- заголовка на ваших старых клиентах, вы можете плавно ввести новый формат рядом со старым, заставив новые клиентские приложения принимать новый формат.
Вариант 2: Я лишь наполовину серьезно отношусь к этому варианту, но я подумал о продвижении нового типа медиафайлов под названием application / hyperxml + xml. Документ будет следовать тем же правилам, что и application / xml, но также будет использовать XLink для гипермедиа. Это позволит людям, использующим javascript для синтаксического анализа XML-документа, также использовать преимущества гипермедиа стандартизированным способом.
Вариант 3: Используйте XHtml. Я не понимаю, почему у вашего парсера проблемы с Xhtml, но верю вам на слово.
There are two important pieces of information your RESTful server will need to process requests, regardless of the underlying markup language: a media type and a URI. Assuming a media type for a given URI would introduce client-server coupling. It would, for example, prevent the same URI from ever serving two different kinds of media type.
XML isn't the only option when designing hypermedia formats. Check out the Sun Cloud API, which defines a hypertext-driven REST API based on JSON (although it appears to not use media type with its hyperlinks). It's not difficult to go from this approach to one that combines media types with hyperlinks.
For example, you could define a JSON data structure called Link that looks like this;
{
"name":"human-readable label for link",
"uri":"http://example.com/resources/123",
"media_type":"application/vnd.com.example.Resource+json"
}
Hypermedia не требует HTML или даже полностью определенных URI в этом отношении. Если ваш тип мультимедиа определяет правило для преобразования некоторых элементов ответа в ресурсы, с которыми можно разыменовать, тогда у вас есть гипермедиа.
<result>1234</result>
Приведенный выше пример в сочетании с правилом типа мультимедиа о том, как разыменовать содержимое элемента результата, является гипермедиа в так же, как:
<result>/foo/1234</result>
с правилом для добавления базового http URI. Пример ниже, где факт разыменования строки http можно оставить неявным.
<result>http://myserver.com/foo/1234</result>
Однако, хотя все они являются гипермедиа и соответствуют этому ограничению, я бы возражал против создания ваших собственных новых правил производства гипермедиа и тегов, если вообще возможно и просто повторно использовать существующие. В первом примере пользователю менее очевидно, что этот элемент представляет ресурс с гиперссылкой, чем в последнем примере.