Является ли конечная точка API отличным от того, какие ресурсы нужно возвращать на основе пользовательских учетных данных RESTful и хорошего дизайна URI?

Ответ 1

ОБНОВЛЕНО 18 марта 2015 года 13:05 CET, чтобы включить отзывы в комментарии к вопросу и ответам.

, стабильность, спокойствие

С точки зрения пуриста, не конечные точки RESTful. Например, в вопросе не указано, содержат ли ответы ссылки на ресурсы, чтобы клиент мог извлекать ресурсы без необходимости знать о том, как создаются URI для ресурсов. Фактически как указано в этом blogpost, практически никакой API, определенный на практике, кроме самой World Wide Web, можно считать RESTful.

Так нет ничего полезного сказать об этих конечных точках? Я думаю, что есть. Мы можем говорить о безгражданстве и idem-эффективности обработки конечных точек, что важно для масштабируемости. И мы можем говорить о безопасности конечных точек, что важно для безопасности.

Для всех конечных точек вы можете указать следующее:

Является ли он без гражданства?

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

Поскольку эти конечные точки обрабатывают запросы GET, являются ли они эффективными?

Конечная точка A): Да, поскольку запрос к конечной точке A, включая учетные данные пользователя, должен рассматриваться как целое: независимо от того, как часто вы повторяете один и тот же запрос с одинаковыми учетными данными, вы всегда будете получать thing ресурсов для аутентифицирующего пользователя.

Однако. Если вы рассматриваете только URI, запрос на самом деле не является эффективным, потому что ответ изменяется в зависимости от предоставленных учетных данных.

Конечная точка B) и C): аналогично A) вы всегда будете получать ресурсы thing <user_x>, предоставленные в URI, независимо от того, как часто вы его повторяете.

Кроме того, запросы также эффективны только с учетом самого URI, все, что вам нужно знать о запросе, находится в URI, учетные данные пользователя могут изменять только представление возвращенных ресурсов thing, а не ресурсы возвращаются.

Поскольку эти конечные точки обрабатывают запросы GET, они безопасны?

Да, потому что запрос не изменяет никаких данных и не имеет каких-либо других побочных эффектов.

Дизайн URI

Хотя с точки зрения пуриста REST перспективы URI считаются неактуальными, в практической ситуации, когда разработчики программного обеспечения и конечные пользователи API используют и обрабатывают дизайн URI, имеют значение.

Имеется ли у конечной точки A хороший дизайн URI?

Да и Нет. Когда этот URI скрыт от пользователя приложения, и это не будет занесено в закладки или предоставлено, этот дизайн будет прекрасен. Однако, когда этот URI открыт для конечных пользователей, этот URI не разработан хорошо, потому что при совместном использовании этого в качестве ссылки получатель не будет видеть одни и те же данные, если только она не будет аутентифицироваться как один и тот же пользователь.

У конечных точек B и C есть хороший дизайн URI?

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

Итак, вместо определения всех трех конечных точек вы могли бы выбрать только конечные точки B и C, потому что они могут предоставить все, что может предоставить конечная точка A, а также очевидно, что URL-адрес запрашивается.

Пожалуйста, дайте мне знать, что вы думаете. Спасибо!

- Фредди Снайдер

Ответ 2

Я изменил свой старый ответ. Я предполагаю, что мы говорим о веб-документах, поэтому /things/1 идентифицирует веб-документ, а не реальную вещь. (Подробнее об этом здесь: http://en.wikipedia.org/wiki/Dereferenceable_Uniform_Resource_Identifier и здесь: https://tools.ietf.org/html/rfc6920.)

1) Является ли конечная точка RESTful?

2) Имеет ли конечная точка A хороший дизайн URI?

3) Являются ли конечные точки B и C RESTful?

4) Имеют ли конечные точки B и C хороший дизайн URI?

Ответ на вопросы 1 и 3 да, вы можете отправлять разные представления одного и того же ресурса пользователям с разными разрешениями. (Если вы хотите кэшировать эти ответы, вы должны сделать это, используя заголовок переменной.)

Ответ на вопросы 2 и 4 зависит от того, как вы определяете "хороший дизайн URI". Ваши URI отлично действуют и поскольку REST не имеет никакого ограничения структуры URI, и нет стандартов о том, как создавать URI REST для разных приложений (за исключением стандартного URI и стандартного шаблона URI), я бы сказал, что они хороши.

Здесь есть аналогичный вопрос: Дизайн RESTful URL: публичный vs private API, шаблон дизайна API hierhachy, URI и дизайн URL? об этом иерархическом или обычном URI проблема, если вы хотите прочитать более подробное мое мнение об этом.

Ответ 3

Ну, во-первых, в HTTP представление ресурса обрабатывается заголовком Content-Type и Accept.

Но клиенты могут предлагать только формат, который они предпочитают. Сервер отвечает за представление, которое он хочет.

Говоря о безопасности, для меня совершенно правильно вернуть представление, основанное на уровне безопасности токена.

Говоря о вашем URL, я всегда предпочитаю параметры URL вместо параметров запроса (некоторые двигатели не кэшируют запрос GET с параметрами запроса).

Но это зависит от структуры ваших данных. Если user_id находится внутри вещей, он должен быть представлен в URL:/things/user_id/xxxxx.

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

Ответ 4

Это очень хороший вопрос и точный вопрос, который я задавал себе при разработке API для проекта, над которым я работаю. Я относительно новичок в REST, поэтому переживаю крутую кривую обучения и поэтому далек от того, чтобы быть экспертом!

Я читал "Поваренную книгу веб-сервисов RESTful" от Subbu Allalaraju.

Для чего это мои мысли, они очень похожи на тот ответ, который вы предоставили себе. На практике я уверен, что общий сценарий заключается в том, что учетные данные для проверки подлинности влияют на информацию, возвращаемую для того же URI. Учетные данные являются фактически просто еще одним параметром запроса.

1) Является ли конечная точка RESTful?

Да, он не имеет статуса, поскольку учетные данные для проверки подлинности передаются от клиента с запросом.

Идемпотент по https://www.w3.org/Protocols/HTTP/1.0/spec.html раздел 10.2 Авторизация "Ответы на запросы, содержащие поле авторизации, не кэшируются". поэтому одни и те же учетные данные всегда будут получать тот же результат (аутентификационный список пользователей).

2) Имеет ли конечная точка A хороший дизайн URI?

Нет, это фактически то же самое, что и конечная точка B или C, где пользователь делает запрос на получение своих вещей, но с меньшей гибкостью и ясностью.

3) Являются ли конечные точки B и C RESTful?

Да, они без гражданства и идемпотентны.

4) Имеют ли конечные точки B и C хороший дизайн URI?

Да, я думаю, что любой из них может быть действительным дизайном. Бесконечные дискуссии о плюсах и минусах каждого подхода!

Я решил пойти с чем-то подобным в своем собственном API.

GET/user/01/вещи (правильно аутентифицируются как пользователь 01)

Ответ 200 OK: Да, пользователь 01, конечно, вы можете видеть свои собственные вещи.

GET/user/01/вещи (правильно аутентифицируются как пользователь 02)

Ответ 200 OK: Да, пользователь 02, вы являетесь суперпользователем и можете видеть, какие вещи пользователь 01 имеет (или, возможно, подмножество).

GET/user/01/вещи (правильно аутентифицируются как пользователь 03)

Ответ 403 Запрещено: нет пользователя 03, хотя вы правильно аутентифицированы, вы просто обычный пользователь и не можете видеть, что делает пользователь 01. Или вы можете вернуть Response 200 OK и включить аналогичную информацию в данные ответа, все сводится к тому, как вы разрабатываете свой API и сколько информации вам нужно, чтобы иметь возможность вернуться в этой ситуации, я думаю, что любой из подходов действителен.

GET/user/01/вещи (неверная аутентификация как пользователь 01)

Ответ 401 Несанкционированный:

Список кодов состояния HTTP