Можно ли использовать HATEOAS для команд в стиле RP C?

Question

В REST ресурсы идентифицируются по их URI, и разрешенные операции ограничены доступными HTTP-глаголами. RESTfull API - это унифицированный интерфейс, обеспечивающий основные c операции CRUD для ресурсов через HTTP.

Наконец, архитектура REST утверждает, что ресурсы должны содержать гиперссылки для клиента для дальнейшего прохождения API. Это называется HATEOAS (Гипертекст как двигатель состояния приложения). Гиперссылки отделяют клиентский код от деталей реализации интерфейса.

REST Полезно ли использовать ссылки HATEOAS для передачи обязательных команд, нацеленных на ресурс в стиле RP C? Я думаю, что это не нарушит единый интерфейс, так как вся информация приведена в ссылке. Рассмотрим следующий пример, где действие не помещается в глагол HTTP.

GET /foo/1

{ id: 1, foo: "foo", links: { self: "/foo/1", doAction: "/foo/1/do-action" } }

POST /foo/1/do-action

Или следует Я просто использую параметры запроса для передачи информации о команде в конечную точку ресурса или моделирую команду как собственный ресурс?

Answer 1

REST полезно использовать ссылки HATEOAS для передачи обязательных команд, нацеленных на ресурс в стиле RP C?

REST - это архитектурный стиль; если вы хотите понять, как это работает, вам следует искать аналоги в приложениях, созданных с использованием этого стиля. Для REST наиболее известным из этих приложений является World Wide Web.

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

{ 
    id: 1,
    foo: "foo",
    links: {
        self: "/foo/1",
        doAction: "/foo/1/do-action" 
    }
}

Итак, с точки зрения REST возникает вопрос: «Как сделать компоненты назначения знают, что делать с doAction? "

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

В AtomPub стандарт определяет семантику отношений ссылок в различных документах, поэтому любой клиент Atom общего назначения будет знать, как интерпретировать данные, содержащиеся в ответы.

(В некотором смысле определения отношений ссылок в Atom во многом похожи на определения A и FORM в HTML; они имеют общую полезность).

Так что в вашем В контексте, подсказка «doAction» должна информировать клиента о чем-то интересном, что можно сделать (разместите здесь видео с кошкой). target uri не должно иметь значения для клиента; он должен просто отправлять запрос там, где ему говорят.

Правописание target-uri здесь вообще не имеет значения; но интересный случай, который нужно рассмотреть, это то, что происходит, когда target-uri совпадает с тем, который вы используете где-то еще, например:

{ 
    id: 1,
    foo: "foo",
    links: {
        self: "/foo/1",
        doAction: "/foo/1" 
    }
}

HTTP имеет простую семантику аннулирования кэша встроенный в стандарт; по сути, ваша цель для doAction сообщает клиенту, какое кэшированное представление будет недействительным в случае успешного действия.