Предположим, что у вас есть ресурс/компании, который позволил клиентам искать открытые компании, и вы хотели, чтобы клиенты могли искать компании по тикеру, расположению и местоположению и промышленностиКак получить ресурс REST с помощью разных методов поиска?
Не могли бы вы сохранить тот же URL-адрес в форме:
Это не кажется правильным. Есть идеи?
Как насчет?
GET /Companies?ticker=MSFT
GET /Companies?country=USA
GET /Companies?country=USA&industry=software
Важно определить ресурс. Ресурс - это «список компаний». Его тип носителя может быть списком Atom или только HTML-документом с использованием тегов UL LI. Параметры запроса влияют на содержимое списка, но концептуально он по-прежнему является «списком компаний».
Вы можете создать отличный ресурс, такой как
GET /Companies/USA
но сделать вам действительно нужно. Собираетесь ли вы отправляться в/Компании/США? Собираетесь ли вы удалить/Компании/США? Если ваше приложение не требует возможности выполнять дополнительные операции над этими конкретными наборами компаний, то зачем их моделировать в качестве отдельных ресурсов?
В качестве дополнительной заметки к этой дискуссии я хотел бы более четко различать, когда я обращаюсь к ресурсу, который представляет собой единую сущность и список. т.е.
GET /Companies/USA
GET /Company/MSFT
Я понимаю, что это не так, как некоторые из популярных фреймворков работать, но я нашел его полезным различие.
Вы можете принять любой из них, но затем вернуть заголовок Location: заголовок, указывающий на канонический адрес (предположительно GET/companies/msft).
Последние два запроса возвратят несколько компаний. –
У вас есть только одна компания, но несколько способов добраться до нее, поэтому я бы, вероятно, определил/компании/[уникальное имя], а затем различные вещи, такие как/компании/byticker/msft и/companies/bylocation/США и т.д.
Это не очень RESTful подход. – workmad3
@ workmad3 Если вы собираетесь использовать эту фразу, вам нужно объяснить, какое нарушение REST нарушено. Мы видим * WAY * слишком много использования фразы «это не RESTful» без какого-либо обоснования. –
Это не RESTful, потому что ресурсы должны иметь уникальные имена. Если у вас есть несколько запросов, которые возвращают «одно и то же», тогда они должны возвращать уникальное имя ресурса, который затем может быть извлечен, а не сам ресурс. Наличие уникального имени важно для согласованности кеша в архитектуре REST. Одно имя, одна политика кэширования, одно «место», чтобы получить его, изменить его и т. Д. –
Мы хотели бы выполнять операции на уровне компании. Т.е.:/компании/msft –
См. Мое обновление. Я нахожу url/Companies/msft вводящим в заблуждение. Возвращает ли он список компаний, у которых есть тикер msft? или он возвращает представление ресурса компании? В любом случае, это мое предпочтение. Именование url примерно так же значимо для REST, как именование классов для объектно-ориентированного программирования. –
Получил. Согласен. –