Это плохой URL REST?

Я только что читал о URL-адресах REST и видел следующий пример:

/API/User/GetUser

Теперь, если это обращение через HTTP с помощью глагола GET, это не плохой URL-адрес, потому что он описывает действие (GET) в URL-адресе?

+3
источник поделиться
6 ответов

Нет такой вещи, как URL-адрес REST. На самом деле, слово REST URL - это в значительной степени оксюморон. Hypermedia as Engine of State State Constraint гарантирует, что URL-адреса не имеют значения: вы всегда используете ссылки, представленные вам сервером. Вы никогда не видите, читаете или вводите URI где угодно. (Точно так же, как просмотр в Интернете: вы не смотрите на URL-адрес ссылки, не читаете ее, не запоминаете и не вводите в адресную строку, просто нажимаете на нее и не заботитесь о том, что она на самом деле говорит.)

Термин REST URL означает, что вы заботитесь о своих URL-адресах в своей архитектуре REST. Однако, если вы беспокоитесь о своих URL-адресах в своей архитектуре REST, вы не являетесь RESTful. Поэтому URL REST является оксюмороном.

[Примечание. Правильный дизайн URI очень важен для URI-интерфейса URI, особенно для части I. Кроме того, существует множество хороших причин для удобства URL. Но оба они не имеют ничего общего с REST.]

+4
источник

Это скорее соглашение, чем жесткое правило, но я бы предпочел увидеть что-то вроде /API/User/7123. GET/POST/etc описывает глагол действия, поэтому его включение в URL делает его излишним. И в этой ситуации нет причин не следовать хорошо зарекомендовавшим себя методам.

Вот несколько хороших вещей: Понимание REST: глаголы, коды ошибок и аутентификация

+9
источник

GET /API/User/7123, чтобы получить пользователя 7123.

POST до /API/User, чтобы создать пользователя.

PUT до /API/User/7123 для обновления пользователя 7213.

УДАЛИТЬ до /API/User/7123, чтобы удалить пользователя 7213.

Как говорили другие, REST не является жестким и быстрым правилом, более подход.

Используйте http verbs для достижения действий на основе расположения ресурсов (URL).

Но в основном делайте то, что наиболее подходит для ваших нужд.

EDIT: Помните, однако, что глаголы о определяют предполагаемую семантику связи, а не реализацию сервера.

EDIT2: Это мой любимый ответ, касающийся REST.

+6
источник

Лучше будет иметь /API/User/ 7123 и использовать метод GET/POST для обозначения операций

+5
источник

Это не обязательно плохо... это больше связано с каркасом, который вы используете для создания своих URL-адресов для отдыха. Ссылка @Infinity опубликовала хороший ресурс, но не ограничивает себя теорией множеств, потому что это может вызвать чрезмерную работу в определенных рамках.

Например, нет причин, по которым вы не захотите запускать GET on/API/Users/{id}/Delete, чтобы отобразить сообщение типа "вы уверены" перед использованием метода DELETE.

+3
источник

/API/User/GetUser не является RESTful. Использование глагола для идентификации ресурса - это нехорошо. Пример url все еще действителен, но это тоже не делает его правильным. Это неверно, поскольку следующее объявление

String phoneNumber = "jhon@gmail.com";
+1
источник

Посмотрите другие вопросы по метке или Задайте вопрос