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

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

  /system/resource

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

  /system/resource/related/otherresourcename

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

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

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

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

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

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

ОТВЕТЫ

Ответ 1

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

Ответ 2

hmm, трудно ответить (ваш пример для меня слишком абстрактный).

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

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

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

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

Состояние заказа на поставку как ресурс

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

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

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