Нужна обратная связь по качеству REST URL

Question

Для получения последнего действительного адреса (вошедшего в систему пользователя), насколько RESTful является следующий URL?

GET /addresses/valid/latest

Вероятно,

GET /addresses?valid=true&limit=1

лучше, но оно должно затем верните список. И я хотел бы вернуть объект, а не список.

Любые другие предложения?

Answer 1

Ваша структура URL не имеет ничего общего с тем, как RESTful что-то.

Итак, давайте предположим, какой из них "лучший". Также немного сложно сказать, довольно субъективно.

Я бы вообще избегал такой схемы, как /addresses/valid/latest. Это своего рода предположение, что есть «последний ресурс» в «действительной коллекции», в «коллекции адресов».

Так что мне больше нравится ваше другое предложение, потому что оно предполагает, что вы используете Коллекция «адресов», фильтрация по допустимым элементам и показ только 1.

Если вы не хотите, чтобы все виды параметров, я был бы более склонен найти шаблон URL, который не буквально «адреса, но только допустимо, но только по последнему слову, но подумайте, какова цель конечной точки. Может быть, что-то, что легче запомнить, например /fresh-address =)

Answer 2

насколько RESTful является следующим URL?

Любой идентификатор, который удовлетворяет правилам производства , описанным в RF C 3986, является RESTful.

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

Рассмотрим Поиск в Google : заботится ли ваш браузер о том, какой URI используется в качестве цели формы поиска? Ваш браузер заботится о ссылках, предоставляемых Google с каждым результатом поиска? В обоих случаях браузер просто выполняет то, что ему говорят, то есть он создает HTTP-запрос на основе представления состояния приложения, предоставленного сервером.

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

Но есть контексты, в которых легко угадываемый URI не , что вы хотите. См. Mark Seemann 2013 .

Поскольку содержимое URI semanti c зарезервировано для использования только сервером, из этого следует, что сервер может выбрать кодирование этой информации в сегменты пути или часть запроса. Или и то и другое.

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