Как должен выглядеть RESTFUL API для задач, если мне нужно два GET? - PullRequest
Новая
       8

Как должен выглядеть RESTFUL API для задач, если мне нужно два GET?

0 голосов
/ 14 апреля 2019

Я хочу разработать RESTful API для сервиса очистки веб-сайтов. Пользователь делегирует задачу службе. Каждое задание - это веб-сайт, который нужно создать. Пользователь может проверить статусы задач. Когда задача выполнена, пользователь может получить результат задачи. Статус может быть «Ожидание», «Выполняется» или «Готово», когда это сделано, пользователь может получить данные.

Что у меня сейчас есть:

  • POST /tasks - опубликовать URL для очистки

  • GET /tasks - возвращает список задач

Мне нужны еще две конечные точки: одна для получения статуса задачи, а другая для получения данных с веб-сайта. Как должен выглядеть GET?

  • GET /tasks/{id} - вернуть статус? Или вернуть данные?

Или, может быть

  • GET /tasks/{id}/status
  • GET /tasks/{id}/data

Но что вернет /tasks/{id}/ тогда?

А что, если бы я также хотел представить записанные данные в виде html? Должен ли я использовать

  • GET /tasks/{id}/data или GET /tasks/{id}/result

Ответы [ 3 ]

0 голосов
/ 14 апреля 2019

Я действительно не знаю ограничений, но GET / tasks / {id} может вернуть статус и данные, если они доступны.

Если вы предпочитаете не делать этого (например, если получение данных слишком часто будет проблемой с точки зрения производительности), представляется разумным иметь: 

GET /tasks/{id} @returns status and other plain task fields

, а затем: 

GET /tasks/{id}/scrappeddata @returns data

Почему?Потому что этот способ, вероятно, наиболее соответствует вашей модели (и / или ментальной модели в сознании ваших пользователей API).

Общие правила именования ресурсов, приведенные в руководстве по API отдыха, полезны: https://www.restapitutorial.com/lessons/restfulresourcenaming.html

0 голосов
/ 15 апреля 2019 
POST /tasks - post a URL to scrape
GET /tasks - returns a list of tasks

Это хорошо.Обратите внимание, что при успешном выполнении POST начинает действовать недействительность кэша. Общие клиенты будут знать, что ранее возвращенные представления списка задач больше не действительны. 

GET /tasks/{id} - return a status? Or return the data?

Почему не оба?/tasks/{id} идентифицирует ресурс;Вы можете использовать любой вид представления, который вам нравится.Нет причин, по которым представление не должно включать необязательные элементы.

(Herustic: как будет выглядеть веб-страница ?это одна концепция? Если нет, то это, вероятно, может быть единственным ресурсом в вашем API.)

что, если бы я также хотел представить записанные данные в виде HTML?

Один и тот же идентификатор подходит для нескольких представлений;клиент может использовать заголовок Accept для описания своих предпочтений для сервера.

Возможно, вы захотите немного подумать над тем, как клиент знает, какие представления возможны.В Интернете спецификация для HTML описывает множество различных видов ссылок - например, браузеры могут указывать разные предпочтения, когда они встречают тег сценария или тег изображения.Вам понадобится нечто подобное в ваших собственных типах мультимедиа.

Нет ничего плохого в том, что 1023 * решают, что все они также должны быть разными ресурсами.Любой подход может быть реализован способом, который соответствует архитектурному стилю REST.

0 голосов
/ 14 апреля 2019

Нет жестких правил, когда дело доходит до именования маршрутов для RESTFUL API.Вы можете придерживаться соглашения, знать лучшие практики, советы SO, но, в конце концов, именно вы разрабатываете свой API, так что вы лучше, чем кто-либо другой, знаете, что подойдет для вашего конкретного случая использования.

Поищите "рекомендации по именам rest api" или "как структурировать маршруты остальные api", и вы получите множество идей.

Оба предложения, сделанные мной и @jonrsharpe, верны, они истекливам, чтобы определить, что имеет смысл для вашего проекта.

...