ASP.NET Web Api Лучшие практики для длительного создания, опроса, доставки длительных заданий - PullRequest
Новая
       21

ASP.NET Web Api Лучшие практики для длительного создания, опроса, доставки длительных заданий

0 голосов
/ 09 мая 2018

Мы работаем над новым RESTful API, используя ASP.NET Web API. Многие наши клиенты получают от нас ночные данные. Для каждого канала мы запускаем запланированное задание агента SQL, которое запускает хранимую процедуру, которая выполняет пакет служб SSIS и доставляет файлы по электронной почте / FTP. Несколько клиентов выиграют от возможности запускать это задание по требованию, а затем получать либо двоичный файл (xml, xls, csv, txt и т. Д.), Либо прямую передачу данных в формате JSON или XML.

Основная проблема заключается в том, что подача обычно занимает некоторое время. Большинство из них запускаются в течение нескольких минут, но есть пара, которая может занять 20 минут (часть проекта оптимизирует эти задания). Мне нужна помощь в поиске лучшей практики для настройки этого API.

Вот наши действия и предлагаемые REST звонки

Создать запрос фида 

POST ./api/feedRequest
Status 201 Created

Возвращает feedID в теле (JSON или XML)

Мы думали, что POST будет правильным типом запроса, потому что мы создаем новый запрос.

Статус подачи опроса ПОЛУЧИТЬ ./api/feedRequest/ndomfeedID‹

Status 102 Processing (feed is processing)
Status 200 OK (feed is completed)

Отмена запроса фида 

DELETE .api/feedRequest/{feedID}
Status 204 No Content

Отменяет запрос на подачу.

Получить канал 

GET .api/feed/{feedID}
Status 200 OK

Это вернет данные канала. Мы, вероятно, передадим параметры в заголовок, чтобы указать, как им нужны их данные. Для установки feedType в значение "direct" потребуется настройка JSON или XML в Content-Type. Установка для feedType «xml», «xls», «csv» и т. Д. Передаст файл двоичных данных обратно пользователю. Для некоторых каналов это пользовательский шаблон, указанный в определении канала, который уже хранится в наших таблицах.

Вопросы

  1. Похоже, мы на правильном пути? Любые непосредственные предложения или проблемы?

  2. Мы пытаемся решить, иметь ли ресурс / feed и ресурс / feedRequest или оставить все это в / feed. Приведенный выше сценарий является двухресурсным Единственный ресурс будет POST / feed для запуска запроса, PUT / feed для проверки состояния, GET / feed, когда это будет сделано. PUT не чувствует себя хорошо, и сейчас мы склоняемся к вышеуказанному решению. Это кажется правильным?

  3. Нас беспокоит очень большая отдача набора данных. Должны ли мы разбивать их на части или служба REST будет обрабатывать эти большие возвраты. Некоторые каналы могут превышать 100 МБ.

  4. У нас также есть изображения, которые могут быть сгенерированы, чтобы сопровождать канал, они упаковываются в отдельный файл при вызове хранимой процедуры и пакета канала. Мы можем оставить все это в одном запросе и вызвать GET / feed / {feedID} / images при возврате.

  5. Кто-нибудь знает о передовой практике или хорошем примере GitHub, на который мы могли бы обратить внимание, что-то похожее на технологии MS? (Мы также рассмотрели возможность перехода на ASP.NET Core.

...