2010-02-05 2 views
3

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

/API/Пользователь/GetUser

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

+5

Стоит отметить, что сам REST просто требует, чтобы URL-адреса однозначно идентифицировали ресурс и не должны придать какое-либо конкретное семантическое значение. Потребитель сервиса должен рассматривать URL как непрозрачный и использовать принцип, согласно которому представления ресурсов будут содержать URLS для других ресурсов для навигации по службе. Сказав все, что его неоспоримо полезные в качестве «потребителя» человека, чтобы иметь возможность интерпретировать услуги URL-адрес в виде иерархической структуры. – Joe

+0

@Joe: Я думаю, вы упустили точку вопроса, которая, как я ее читаю, касается глаголов vs существительных, а не иерархии в смысле файловой системы. – 2010-02-05 16:24:20

+0

@Roger верен, меня интересовали мнения людей на глаголе в url ... – AwkwardCoder

ответ

4

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

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

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

+0

Нет такой вещи, как URL-адрес REST? Микроформаты не согласятся http://microformats.org/wiki/rest/urls – gingerbreadboy

+1

@ Jörg - Я понимаю вашу точку зрения, но в реальном мире, где у вас есть разработчики, создающие API RESTful, к которым обращаются через HTTP, я должен рассмотреть это, чтобы попытаться понять их мышление – AwkwardCoder

+1

URL-адрес для отдыха - это абсурд, и микроформаты просто совершенно необразованны в этом вопросе. Upvoted. – SerialSeb

9

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

Вот некоторые хорошие вещи: Understanding REST: Verbs, error codes, and authentication

+6

+1: Глагол не должен быть частью идентификации ресурса. –

+0

@SLott Что относительно/Словарь/Английский/Удар, чтобы получить определение слова «Kick»? –

+1

@ Darrel Miller: токен «Kick» не используется в качестве глагола; он используется как строка графем для определения определенного слова. Это не глагол, потому что он используется в качестве инструкций о том, что делать. Это просто персонажи. –

3

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

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

5

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

6

GET /API/User/7123 получить пользователю 7123.

POST к /API/User для создания пользователя.

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

DELETE для /API/User/7123 удалить пользователя 7213.

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

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

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

EDIT: Помните, что глаголы составляют около defining the intended semantics of the communication, а не реализацию сервера.

EDIT2: This is my favourite answer regarding REST.

+2

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

+2

Я бы даже пошел дальше: REST - это ничего, кроме четырех жестких правил. (На самом деле, я считаю, что первые три являются просто предпосылками для ограничения HATEOAS. Кроме того, я считаю, что они здравый смысл. Таким образом, это действительно просто * одно жесткое правило.) –

+0

@Darrel, ни одно из правил скажите что-нибудь о глаголах и существительных в URL-адресе, равно как и мой ответ. – gingerbreadboy

1

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

String phoneNumber = "[email protected]"; 
Смежные вопросы