REST URIs и операции на объекте, который может быть прокомментирован, отметил, оцененный, и т.д.
Существует nice-скрипт , с помощью которого вы можете контролировать внутренний процесс. Это означает, что вы можете определить свой собственный способ генерации данных на каждой итерации, наряду с передачей данных из каталога.
В этих сценариях автор загружает данные из файла .npy , в то время как вам необходимо прочитать изображение, которое можно сделать с помощью matplotlib , CV или другой пакет. Используйте его по своему выбору. Затем добавьте функцию, которую вы хотите использовать для увеличения , такую как вращение, масштабирование, сдвиг и т. Д.
7 ответов
Большая часть того, что у Вас есть хорошие взгляды. Было только несколько странных вещей, которые я видел. Когда я соединил свои URL, я пытаюсь следовать за этими четырьмя принципами.
Очистите лук
Если Вы заставляете R в REST действительно быть ресурсом затем, URL ресурса должен смочь быть отогнутым и все еще значим. Если это не имеет смысла, необходимо заново обдумать, как организовать ресурс. Таким образом в случае ниже, каждый имеет смысл. Я или смотрю на определенный объект или набор объектов.
/movies/horror/10/
/movies/horror/
/movies/
Следующее кажется забавным мне потому что flag не ресурс, это - свойство movie.
/movies/5/comments/8/flag -> Funny
/movies/5/comments/8/ -> Gives me all properties of comment including flag
Определите представление
Последняя часть URL описывает, как показать ресурс. URL /movies/horror/ говорит мне, что у меня будет набор фильмов усовершенствованным ужасом. Но могли бы быть различные способы, которыми я хочу отобразить тот набор.
/movies/horror/simple
/movies/horror/expanded
Простое представление могло бы просто быть заголовком и изображением. Расширенное представление дало бы намного больше информации как описание, резюме и оценки.
Помощники
После того, как ресурс был ограничен, и надлежащее представление вычислено, параметры строки запроса используются для помощи UI с небольшим материалом. Наиболее распространенные параметры строки запроса, которые я использую,
p => Page
n => number of items to display
sortby => field to sort by
asc => sort ascending
Таким образом, я мог закончить с URL как
/movies/horror/default?p=12&n=50&sortby=name
Это даст мне список movies ограниченный фильмами ужасов с представлением по умолчанию; запуск на странице 12 с 50 фильмами на страницу, где фильмы отсортированы по имени.
Действия
Последней необходимой вещью является Ваше действие с ресурсом. Действие является или базирующимся набором или базирующимся объектом.
/movies/horror/
GET -> Get resources as a list
POST -> Create, Update
/movies/horror/10/
GET -> Get resource as item
POST -> Update
Я надеюсь, что это помогает.
Ну, способ, которым я вижу его часть информации, которую Вы возвращаете теперь как объекты, мог просто быть добавлен к метаданным своего родительского объекта.
Например, оценка могла быть частью ответа/movies/5
<movie>
<title>..</title>
..
<rating url="movies/ratings/4">4</rating>
<tags>
<tag url="movies/tags/creative">creative</tag>
...
Удаление тега просто означает отправлять вышеупомянутый ответ без того тега.
Также запросы должны войти в переменные URL, я верю: /movies/?startsWith=Forrest%20G&orderBy=DateAdded
Я не соглашаюсь с редактированием. Запросы должны быть определены querystrings согласно сообщению Martijn Laarman. т.е.:
/movies?genre=action&timeframe=90s&lbound=20&ubound=40&order=desc
Это - потрясающий первоначальный проект для спецификации API REST. Следующий шаг был бы для определения кодов ожидаемого дохода (как Вы, не сделал с "404 Никакими Тегами, Доступными"), приемлемые Типы контента и доступные типы контента (например, HTML, JSON). Выполнение, которое должно выставить любые дополнительные трещины, которые необходимо будет выработать.
На основе моего понимания ROA (я нахожусь только на главе пятью из УСПОКОИТЕЛЬНЫХ веб-сервисов) это выглядит хорошим мне.
@Nelson LaQuet:
Используя методы HTTP, поскольку они на самом деле определяются, дает Вам безопасность знания, что выполнение Получения на чем-либо на веб-сайте или сервисе не съест Ваши данные или иначе исказит ее. Как пример (указанный в УСПОКОИТЕЛЬНЫХ веб-сервисах) веб-Акселератор Google ожидает это поведение - как указано в FAQ - и по-видимому другие сервисы делают также.
Также это получает Вас idempotency бесплатно. Это делает ПОЛУЧЕНИЕ, УДАЛИТЕ, НАПРАВЛЯЙТЕСЬ или Поставьте ресурс, несколько раз совпадает с выполнением его только однажды. Таким образом, если Ваш запрос приводит к сбою затем все, что необходимо сделать, выполняется это снова.
Это не REST.
REST API не должен определять фиксированные имена ресурсов или иерархии (очевидная связь клиента и сервера). Серверы должны иметь право управлять своим собственным пространством имен. Вместо этого разрешите серверам инструктировать клиентов о том, как создавать соответствующие URI, например, как это делается в формах HTML и шаблонах URI, путем определения этих инструкций в типах мультимедиа и связях. [Отказ здесь означает, что клиенты принимают структуру ресурсов из-за внеполосной информации, такой как стандарт для домена, который является ориентированным на данные эквивалентом функциональной связи RPC].
http: //roy.gbiv .com / untangled / 2008 / rest-apis-must-be-hypertext-driven