Как обеспечить предоставление ссылок в службе RESTful с использованием представления данных, отличного от XML?

В последнее время я много читаю о том, как реализовать действительно RESTful WS. Многие люди связали со статьей здесь, в которой описываются несколько ограничений, которые разработчики должны иметь в виду, если хотите, чтобы в конечном итоге были созданы сервисы, соответствующие концепция REST.

Несмотря на то, что сообщение явно важно, нам, к сожалению, довольно сложно понять простых смертных, и различные люди пытались расшифровать его. Возможно, лучшее объяснение, с которым я столкнулся, можно найти здесь здесь, где автор дает конкретный пример того, почему многие API "RESTful" там действительно существуют вообще не являются RESTful и показывают, как можно исправить ситуацию.

Его предложение в значительной степени опирается на использование встраивания ссылок в представлениях открытых ресурсов и имеет большой смысл: я могу четко следовать логике и хотел бы использовать такие методы самостоятельно в ряде сервисов, которые я разрабатываю, однако У меня проблема, я не уверен, как я должен решить: а именно, как следует предоставлять такие ссылки, если используемые представления данных не XML, а что-то вроде JSON?

Все, что говорит автор, имеет прекрасный смысл в мире XML, но я не могу четко видеть, как это можно применить к другим представлениям контента?

Очень интересно услышать мнения других людей и посмотреть, как люди могут решить эту проблему в своих собственных API REST, основанных на XML.

[edit]: поскольку я написал этот вопрос, я нашел следующий полезный ссылки. Пройдите длинный путь, чтобы ответить на мой вопрос, но меня все еще интересуют мнения других людей.

Ответ 1

Я долго боролся с этим вопросом. Я пришел к двум выводам: а) повторно изобретать XML с другим синтаксисом (в основном, что предлагают эти ссылки), или b) принять решение о некоторых простых фиксированных соглашениях.

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

Во-первых, это значение всегда считается URI в некоторых случаях. Приложение знает свой URI, потому что это то, о чем говорит наш тип носителя.

{"form_type": "whatever", "validator": "http://example.com/validatorA"}

Во-вторых, значения возвращаемого структурирования могут быть либо типичным стандартным типом (int, string, list, object, и т.д.), либо объектом с ключом "magic" __ref__. Это часть нашего определения того, как мы определяем тип мультимедиа, который тоже выглядит ( "__" также является незаконным в именах свойств нашими правилами приложения, поэтому он никогда не должен появляться). Это приложение позволяет разыгрывать ценность на досуге.

{"owner": "john", "attachment": {"__ref__": "http://..."}}

Это работает для нас. Большую часть времени мы заботимся о том, что значением является строка "john" , и меньше об абстрактной концепции "john" - ресурс Владельца (с его содержанием не только уникальный идентификатор "john" ).

Для наших нужд мы торгуем простотой и производительностью для выразительности и правильности REST. В реальном мире, это не слишком большая сделка, чтобы иметь внеполосную информацию, которая гласит: "Идите в /users/ $username для получения дополнительной информации", когда результат предоставляет всю информацию, необходимую в 99% случаев.

Наш план - при необходимости в будущем - это привязать ссылку, добавив атрибут __ref__.

{"owner": "john", "owner.__ref__": "http://ex.com/users/83j9io"}

Хотя это не так полно, как ссылки, которые вы предоставляете, я думаю, что это разумный баланс. Хотя мне нравится идея, что каждое значение может иметь ссылку на свой уникальный ресурс и другие метаданные (например, описанные в документе json-collections doc, на который вы ссылаетесь), я думаю, что информация будет посторонней в большинстве случаев. Простой список значений шаров по размеру, но вам действительно нужно знать каждый адресуемый URI, версию, id и т.д.?

Он также вводит раздражающие осложнения в коде, имея в виду ".value" или ".members" (и все семантики, которые дает дополнительный доступ) вместо того, чтобы использовать языковые конструкции. Эта модель ".value" на самом деле является тем, что мы делаем на стороне сервера, и ее допустимо только из-за всех усилий, чтобы сделать их похожими на стандартные типы данных, а не на оболочки.