Конечные точки SCIM и другие расширенные ресурсы в SCIM

URL-адреса всегда чувствительны к регистру. Однако имена HOST - нет.

http://example.com/User?id=JohnDoe и http://ExAmPlE.cOM/User?id=JohnDoe должны разрешаться в один и тот же ресурс, даже если URL-адреса не идентичны. Но URL-адрес чувствителен к регистру.

Поскольку в спецификации указывается Users, а не users, регистр имеет значение.

Это важно, потому что так сказано в спецификации. Кроме того, если ничто иное, другие, читающие спецификацию, будут использовать Users против users.

Что касается REST, эти URL-адреса не имеют значения, поскольку REST не заботится об URL-адресах.

Но это не ОТДЫХ. Это спецификация на основе HTTP. Это не имеет ничего общего с REST.

Дополнения:

Они могут называть это REST API как угодно, но это не так. Они также называют это «протоколом REST», что не имеет смысла, поскольку REST - это архитектура. HTTP - это протокол. Вы можете создать приложение с архитектурой REST поверх HTTP, но это не обязательно. REST не связан с HTTP.

REST не заботится об URL-адресах по той же причине, что и вы. Ключевым принципом REST является HATEOAS, который по сути определяет ссылки в ресурсах и отслеживает их. Вы знаете, что означает ссылка «Оформить заказ» на Amazon? Нет? Тем не менее, вам все еще удается делать покупки там? Это возможно, потому что вы переходите по ссылке «оформить заказ», а не потому, что знаете, что это за URL.

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

В этой спецификации этого мало.

Рассмотрим в спецификации, как говорится, что управление версиями НЕОБЯЗАТЕЛЬНО. Таким образом, это означает, что URL-адрес может быть / v1 / Users или просто / Users. Какой URL вы кодируете в своем клиенте? Как узнать, какая версия у кого-то установлена? Что, если служба, которую вы используете, ранее не поддерживала версии, а теперь становится версированной? Все ваши URL-адреса ломаются. Если вы хотите, чтобы протокол можно было легко реализовать, добавьте ДОПОЛНИТЕЛЬНЫЕ элементы к основам, например, как получить к нему доступ.

Рассмотрим раздел PATCH, в котором говорится об удалении пользователя из группы. У них есть:

  "display": "Babs Jensen",
  "value": "2819c223-7f76-453a-919d-413861904646"
  "operation": "delete"

Что такое value? Похоже на какой-то «идентификатор пользователя». Тем не менее, URL-адрес должен быть идентификатором пользователя. Будь то http://example.com/Users/1234 или http://example.com/shippingdepartment/v1/Users/1234 или http://example.com/beta/notforpublication/Users/1234. ЭТО уникальный идентификатор. Что вам просто 1234 говорит? Недостаточно.

С HATEOAS ваш клиент не должен «знать», как «создавать» эти URL-адреса, и ошибаться. Сервер сообщает клиенту, что это такое.

Что происходит, когда вы хотите ПОЛУЧИТЬ: http://www.example.com/Users/1234 и они перешли на / v2? В REST по HTTP сервер может ответить 301 Moved Permanently с указанием местоположения: http://www.beta.example.com/v2/users/4567/core. Сервер только что сообщил вашему клиенту, что этот ресурс перемещен. Не только «ID» (с 1234 по 4567), но и путь (/ Users / 1234 к / v2 / users / 4567 / core) и даже HOST (www.example.come to www.beta.example.com) . Как ваш клиент узнает, как создать новый URL-адрес?

Итак, 1234 недостаточно. Непрозрачный URL-адрес намного надежнее. Точно так же, как вам все равно, какое значение имеет указатель в программировании, вас волнует только то, на что он указывает, и почему математика указателя приводит к еще большим проблемам.

И если они использовали URL-адрес в этих группах, тогда у вас могли бы быть группы пользователей с несколькими доменами! Какая оригинальная идея. У вас могут быть пользователи v1 и v2 в одной группе. Все виды вещей.

Что касается № 2, вспомогательных ресурсов и прочего, это дело вкуса - вашего вкуса, как видите, с точки зрения REST высокого уровня клиентам все равно, что вы делаете.