Нарушаю ли я RESTfulness при использовании POST как UPDATE OR CREATE?

«Нарушение RESTfulness» строго не определено.

Хорошей ссылкой на степени REST-подобного поведения в интерфейсе является Модель зрелости Ричардсона, которая разделяет степени поддержки идеалов REST на 4 уровня (где 0 означает «совсем не REST», а 3 означает «полностью REST, но вряд ли кто-то еще делает это»)

Ваш выбор лишь немного отличается от дизайна на основе RESTful HTTP на уровне 2 в рамках этой модели. Однако это своего рода компромисс, с которым приходится сталкиваться многим реальным проектам.

POST достаточно открыт, чтобы при желании он мог быть идемпотентным, но HTTP этого не требует. Таким образом, вы не порвали с HTTP, просто упустили возможность использовать более уместный метод PUT. Обратная ситуация с использованием PUT для неидемпотентной части API была бы более проблематичной.

Как личное мнение, я думаю, что если вы остаетесь самосогласованными при обработке различных методов и маршрутов HTTP и четко документируете это изменение в соответствии с ожиданиями, то вы можете разумно называть свой API «RESTful». Я думаю, что разделения кода ответа 200/201 достаточно, чтобы можно было написать самосогласованный клиент. Хотя я бы предпочел видеть здесь как create, так и update как PUT, это не то, что заставило бы меня задуматься больше, чем на мгновение.

Вы можете рассмотреть возможность поддержки обновить или создать на маршруте сбора (POST /cars в вашем примере) в соответствии с рекомендациями, а также обновить на маршруте элемента (POST /cars/7). Концепция «обновить или создать» достаточно распространена в базах данных и структурах ORM, поэтому ее легко понять. Клиент также может использовать последний маршрут только для обновления, будучи уверенным, что он случайно не создаст новую запись автоматически.

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

Методы также могут иметь свойство «идемпотентности» в том смысле, что (помимо ошибок или проблем с истечением срока действия) побочные эффекты N> 0 идентичных запросов такие же, как и для одного запроса.

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

Метод POST используется для запроса того, чтобы исходный сервер принял объект, включенный в запрос, в качестве нового подчиненного ресурса, идентифицированного Request-URI.

В этом случае вы не создаете новый ресурс, вы просто добавляете новый идентификатор ресурса и удаляете старый идентификатор ресурса. Так что POST неуместен.

Действие, выполняемое методом POST, может не привести к получению ресурса, который можно идентифицировать по URI.

Это может означать все, что вы хотите... Люди используют POST не в творческих целях, когда у них нет вариантов, но вы, конечно, нет.

В нашем API «возможно» обратиться к нужному элементу без URI (например, для его обновления с помощью POST), потому что все части первичного ключа построения URI находятся в теле ресурса, поэтому API знает, к какому элементу клиент хочет получить доступ. .

Вы должны использовать IRI (URL) для идентификации ресурсов, если вы не хотите нарушать ограничение универсального интерфейса (идентификация ресурсов).

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

Вы должны использовать как минимум типы MIME, специфичные для поставщика, если вы не хотите нарушать ограничение универсального интерфейса (самоописательные сообщения).

По определению веб-служба REST соответствует всем ограничениям REST. . Термин RESTful был создан, когда люди, которые понятия не имели о REST, начали называть свои веб-сервисы REST. Итак, после этого ppl создал термин RESTful, что означает, что так называемая служба REST не нарушает ни одно из ограничений REST. После этого срок RESTful тоже был исчерпан. В настоящее время мы различаем API гипермедиа и веб-API. API гипермедиа означает, что веб-служба соответствует ограничению HATEOAS (гипермедиа как механизм состояния приложения). Веб-API может быть любым, который претендует на роль REST.