Вопрос по rest, api – Идентифицировать элемент по идентификатору или слагу в RESTful API

21

В настоящее время я разрабатываю API и столкнулся с небольшой проблемой: Как должен выглядеть URL RESTful API, когда вы сможете идентифицировать элемент по идентификатору или слагу?

Я мог бы придумать три варианта:

GET /items/<id>
GET /items/<slug>

Это требует, чтобы слизняк и идентификатор были различимы, что необязательно указывается в этом случае. Я не могу придумать чистого решения этой проблемы, за исключением того, что вы делаете что-то вроде этого:

GET /items/id/<id>
GET /items/slug/<slug>

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

GET /items?id=<id>
GET /items?slug=<slug>

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

GET /items?ids=<id:1>,<id:2>,<id:3>
GET /items?slugs=<slug:1>,<slug:2>,<slug:3>

Но у этого есть и обратная сторона: что, если кто-то хочет идентифицировать некоторые из предметов, которые он хочет получить с помощью идентификаторов, а другие - слизняком? Смешивать эти идентификаторы будет нелегко.

Что является лучшим и наиболее распространенным решением для этихпроблем? Вообще, что важно при разработке такого API?

Вопрос в вопросе, что за слизняк? Spencer Kormos
Википедия гласит: «краткий текст, удобный для пользователя и SEO, используемый в URL для идентификации и описания ресурса» или что-то подобное. Claudio Albertin

Ваш Ответ

1   ответ
10

например части API Twitter допускают такой синтаксис:https: //dev.twitter.com/rest/reference/get/statuses/show/i

Четвертый вариант - это гибридный подход, при котором вы выбираете один (скажем, ID) в качестве типичного метода доступа для отдельных элементов, но также разрешаете запросы, основанные на слаге. Например.

GET /items/<id>
GET /items?slug=<slug>
GET /items?id=<id>

Ваша маршрутизация будет очевидной картой / items / id для / items? Id =

Возможность расширения до нескольких идентификаторов / слагов, но все еще соответствует REST-парадигме сопоставления URI с базовой моделью данных.

"REST-парадигма сопоставления URI с базовой моделью данных." это то, что я волнуюсь Но я думаю, я пойду с этим. Claudio Albertin
Это почти вопрос кока-колы / пепси в наши дни. :) Я бы сказал, что вы должны поддерживать / items / <uniqueid> для RESTful-сертификации, но также разрешать в запросе строку запроса, которая выполняет поиск по идентификатору или слагу. И я предпочитаю колу. Mike
Поскольку у меня будет несколько параметров запроса для поиска элементов, которые все возвращают массив, было бы разумно также возвращать массив здесь? Вы можете искать слагов, но не можете четко идентифицировать элементы по ним, поэтому кажется логичным вернуть массив. Claudio Albertin
Вероятно, каждый завершенный слаг уникально идентифицирует ресурс, поэтому, если вы включите частичное сопоставление при поиске слагов, я согласен, что массив имеет смысл. С точки зрения того, что кто-то использует API-интерфейсы RESTful, я хотел бы написать как можно меньше кода для разбора: даже для идентификатора, когда вы знаете, что возвращается только одно совпадение, я бы согласился, чтобы вы возвращали массив. Возможно, не «чисто» возвращать массив, если вы знаете, что в нем будет только один элемент, но это экономит мои усилия, чтобы вы были прощены. Mike
Смотря на что-то похожее прямо сейчас. Я чувствую, что вариант частичного сопоставления / возврата массива под URL-адресами с поиском может иметь больше смысла, и просто иметь прямое сопоставление ресурсов, когда используется только существительное объекта. например / items / search? slug = <slug> возвращает массив совпадений, / items? slug = <slug> пытается выполнить прямое совпадение. jasonmcclurg

Похожие вопросы