Ответ 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" на самом деле является тем, что мы делаем на стороне сервера, и ее допустимо только из-за всех усилий, чтобы сделать их похожими на стандартные типы данных, а не на оболочки.