API REST: ресурс должен быть отфильтрован по идентификатору, но идентификатор не указан
Этот метод также отлично работает:
div.container {
display: flex;
justify-content: center; /* for horizontal alignment */
align-items: center; /* for vertical alignment */
}
Для внутреннего <div> единственным условием является то, что его height и width не должны быть больше, чем у его контейнера .
3 ответа
Что должно быть возвращено, если не указан параметр author_id, например, / books в отличие от / books? author_id = 42?
Если URL ресурса действителен
/books, но сервер не может обслуживать этот конкретный запрос, тогда я предпочту HTTP501 Not Implementedкак код ответа. Поскольку сервер не отвечает за эту функцию. Это спорно, поскольку некоторые предпочитают4xxHTTP-коду, но по-моему4xxкода состояния ошибки указует палец на клиентах.W3 Стандартное определение для HTTP 501
10.5.2 501 Не реализовано Сервер не поддерживает функции, необходимые для выполнения запроса. Это правильный ответ, когда сервер не распознает метод запроса и не поддерживает его для какого-либо ресурса.
.
Я решил что если вы нажмете / книги? author_id = 42, вы получите пустую коллекцию, если у автора 42 нет книг, вместо, например, возврата 404.
Это абсолютно нормально.
Следующий вопрос -
Однако в случае, если client_id имеет значение NULL, я не уверен, должен ли я рассматривать этот случай одинаково (т. е. автор с идентификатором null не имеет книг), или если оно должно быть чем-то вроде 400, обрабатывая null как недопустимое значение для client_id
Это тоже хорошо. Поскольку клиент отправляет неверный идентификатор, его можно исправить с клиентской стороны, поэтому
400 Bad Requestподходит для этого случая.
В основном, это зависит от вас, как вы хотите справиться с этим.
Я разработал некоторые API RESTful в соответствии с Руководством API REST API , в котором содержатся лучшие практики.
Согласно их рекомендациям, клиенты REST должны ожидать, что данные коллекции могут быть возвращены в размерах страниц.
И если вы предоставили постраничные результаты, вы также хотите обеспечить фильтрацию для большой коллекции; поэтому фильтруйте коллекцию с автором.
Они используют фильтрацию в стиле «OData» , сортировку и разбиение на страницы. Я процитирую фактическую главу «фильтрация»:
Параметр $ querystring позволяет фильтровать коллекцию ресурсов, которые адресуются URL-адресом запроса. Выражение, указанное с помощью фильтра $ filter, оценивается для каждого ресурса в коллекции, и в ответ включаются только те элементы, где выражение оценивается как true. Ресурсы, для которых выражение оценивается как false или null, или какие ссылочные свойства, которые недоступны из-за разрешений, исключены из ответа (ответ на ваш вопрос: значит, вы должны вернуть пустой результат поискового вызова)
Пример: вернуть все продукты, цена которых меньше $ 10,00
GET https://api.contoso.com/v1.0/products?$filter=price lt 10.00Значение параметра $ filter является булевым выражением.
Во-первых, в вашем примере выше / books? author_id = 42 не успокаивает imo (некоторые религиозные дискуссии, несомненно, будут иметь место). / books / 42 будет «получить мне книгу с id = 42». Вместо этого API должен принимать параметры фильтра из тела запроса в качестве критериев выбора. / books будут включать ВСЕ книги, которые соответствуют встроенным критериям фильтрации, возможность нулевой коллекции.
Если вы хотите, API также может проверить, действительны ли некоторые критерии фильтрации (автора) и возвращать 404, если автор не существует. Это решение API, пользовательский интерфейс только знает, как с ним разговаривать и обрабатывать результат.
Обратите внимание, что именно я предсказал? Религиозная дискуссия вместе с обложками. Прочитайте работу Роя Филдинга и разработку Леонарда Ричардсона.
-
1Что отличает URI от RESTful или нет? URI (в полной мере) - это просто указатель на один ресурс, ничего больше! Кроме того, URI, подобный
/a/b/c, не указывает, чтоcявляется дочерним по отношению кbилиaродительскому элементуb. Это просто личные интерпретации, которые не обязательно обязательно верны! Приложения, следующие за архитектурой REST, вообще не должны интерпретировать URI, так как это легко сломает клиентов, если URI будет когда-либо изменен, вместо этого на самом деле это связано с именем ссылки на связь. Кроме того, это вопрос, ориентированный на упрямые взгляды - & gt; близко причина! – Roman Vottner 13 July 2018 в 17:02 -
2«Вместо этого API должен принимать параметры фильтра из тела запроса в качестве критериев выбора». Это нарушит основной принцип REST, чтобы иметь параметры в теле запроса, вы должны использовать метод POST и в соответствии со стандартами, вы должны использовать метод POST для создания ресурсов. Это может быть исключение, если критерии поиска слишком сложны, тогда да для POST. Но для этого сценария у нас просто есть auther_id. – Vinit 13 July 2018 в 18:00
-
3@Vinit Согласно спецификация POST не обязательно должна создавать ресурс. Семантика зависит от реализации и, следовательно, не дает никаких гарантий клиентам. Это швейцарско-армейский нож, который должен использоваться, если другие операции не подходят. Можно кодировать полезную нагрузку JSON и помещать ее в параметр запроса GET-запроса. Какие методы лучше - это дебаты. Один гарантирует безопасность, идемпотентность и кешируемость из коробки, в то время как другой вообще не дает никаких гарантий, но в конце концов более гибкий. – Roman Vottner 13 July 2018 в 18:35
-
4@RomanVottner. Мой пост выше основывается непосредственно на руководящих принципах Роя Филдинга, который предложил архитектуру REST в 2000 году как часть своего доктора философии. Wiki . И в соответствии с этим, "/ a" представляет собой набор ресурсов "a" в то время как "/ a / b" возвращает или изменяет один ресурс "a". В REST нет / a / b / c – John White 18 July 2018 в 20:29
-
5@Vinit Да, это может пойти в URI, но OP заявил, что хочет использовать authorid как «найти все книги для authorid». Поскольку REST охватывает только извлечение коллекции ресурса или одного ресурса, реляционные действия «до пользователя». Как уже было сказано, это было мое мнение (возможно, я должен был быть более ясным), что данные, отличные от URI, должны быть в теле (я из арены MVVM), так что это логичное место для поиска дополнительной информации. В документе OP / author / 42 автор имеет идентификатор 42. Тело скажет «включить книги». – John White 18 July 2018 в 20:34
PATCH. Если только определенные ресурсы не поддерживают операцию, т. Е.DELETE, 405 следует возвращать, если эта операция вызывается на ресурсе, который ее не поддерживает. Если для данного URI не найдено никакого представления для ресурса, 404 более уместно, так как обычно это не ошибка сервера, что представление не существует. – Roman Vottner 13 July 2018 в 18:47PATCH, он должен вернуть HTTP405 Method not allowed. Коды 4xx указывают, что клиент несет ответственность за ошибку, и клиент должен ее исправить. 5xx указывает, что сервер отвечает, а тот же запрос не будет работать для клиента, пока сервер не исправит его. скажем,/booksпозволяет использовать только методыGET, PUT, и если клиент пытается использоватьPATCH. Теперь, если u вернет HTTP 501, тогда клиент прекратит запрашивать, но если вы вернете HTTP 405 вместо этого, тогда клиент может исправить проблему с помощью методаPUT. Таким образом, код 405 хорош, когда конкретный http-глагол не разрешен – Vinit 13 July 2018 в 20:21PATCH. ВместоPATCHя также мог выбрать проприетарное расширение, напримерLOCK, или что нет. Клиент также не сможет преобразовать запрос к другому методу, то есть когда необходимо одновременно обновлять несколько ресурсов – Roman Vottner 13 July 2018 в 20:40