лучшая практика для булевых результатов REST

Question

у меня есть ресурс

  /system/resource

И я хочу задать системе логический вопрос о ресурсе, который не может ответит обработкой на клиенте (т.е. я не могу просто получить ресурс и просматривать фактические данные ресурса - это требует некоторой обработки на сервере используются данные, недоступные для клиента). например,

  /system/resource/related/otherresourcename

Я хочу, чтобы это было либо true, либо false. У кого-нибудь есть примеры наилучшей практики для этого типа взаимодействия?

Возможности, которые приходят мне в голову:

• использование кода состояния HTTP, тело не возвращается (пахнет неправильно)

• вернуть текстовую строку (True, False, 1, 0) - Не уверен, какие строковые значения целесообразно использовать, и более того похоже, что игнорируется тип носителя Accept и всегда возвращается простой текст

• придумать логический объект для каждого из моих типов носителей поддержки и вернуть соответствующий тип (документ JSON с одним логическим значением результат, XML-документ с одним логическим полем). Однако это кажется громоздким.

Я не особенно хочу долго обсуждать истинный смысл RESTful система и т. Д. - я использовал слово REST в названии, потому что оно лучше всего отражает общий вид системы, которую я проектирую (даже если, возможно, я Я больше склоняюсь к RPC через Интернет, чем к настоящему отдыху). Однако если у кого-то есть мысли о том, как настоящая система RESTful позволяет избежать этой проблемы целиком буду рад их услышать.

Answer 1

хм, сложно ответить (ваш пример слишком абстрактен для меня).

Как правило, вы можете создать такую ​​булеву информацию, как ресурс-данные или как выделенный ресурс. Пример для домена заказов, когда вы хотите знать, завершен ли заказ или нет (логический вопрос). Осторожно, это упрощенный пример (мир заказов гораздо сложнее;)

Проектное состояние заказа в качестве полезной нагрузки данных

HTTP-вызов: HTTP GET /orders

Вернул бы вам 200 OK с полезной нагрузкой (в формате json): { id : "1" , completed : "true" }

Проектное состояние заказа как ресурс

HTTP-вызов: HTTP GET or HEAD /orders/completed/1

Теперь, чтобы получить свой «логический» ответ, вы можете проверить, был ли статус ответа HTTP 404 или 200. 400 сообщит, что заказ еще не завершен, 200 - что он завершен.

Чтобы помочь вам больше, вам нужно быть более конкретным, каков ваш детальный «булев вопрос»? что такое реальный ресурс и связанный с ним ресурс?

Answer 2

Я думаю, что возвращение text / plain было бы самым чистым вариантом. Что касается заголовка accept, если клиент действительно не может обрабатывать простой текст, вы можете вернуться к Json или Xml.
Лично я бы использовал строки «true» и «false». Большинство клиентских языков могут анализировать эти строки по их подходящему значению.