Обработка на основе файлов по сравнению с API REST

Question

У нас есть требование, когда нам нужно обрабатывать 10 000 транзакций один раз в день в автономном режиме (не в режиме реального времени).

Какой из 2-х вариантов предпочтительными являются

1. Пакетный файл с 10000 строк, отправленных один раз в день и обработаны

или

1. АНИ вызова малыми партиями (как Я предполагаю, что отправка 10K строк сразу не является вариантом).

Я был проинструктирован моими архитекторами, что вариант 1 является предпочтительным, и API будет иметь смысл только при небольших размерах партии, поскольку недостатком 2 является то, что лицо, вызывающее API, должно разорвать полезную нагрузку на небольшие куски, когда у них есть вся информация, доступная им сразу.

Я заинтересован, чтобы увидеть, как «2» могут быть жизнеспособным вариантом, поэтому любые комментарии/предложения, которые помогут сделать это, будут очень полезными.

Благодаря Рахул

Answer 1

Это не полный ответ. Однако я хотел бы упомянуть одну из причин в пользу REST API: Validation. Это лучше управляется через API. После того, как файл будет удален в местоположение FTP, вы будете обязаны проверять формат файла. Будет ли легко перенаправить «плохой» файл обратно в исходный код с сообщением, чтобы объяснить возврат?

С вызовом API, если входящее представление не соответствует действующей схеме, например. XML, json и т. Д., То ваша служба может ответить с кодом состояния http 400 Bad Request. Это несут ответственность за отправку данных в правильном формате с потребителем услуги и помогает добиться лучшего разделения проблем.

Answer 2

Дополнительные рассуждения для REST API:

Поскольку файл содержит операции, каждая запись должна быть атомная (если это было не так, например, существуют отношения между записями в файле, то эти записи не должны рассматриваться "сделка"). Поэтому чередование файла на более мелкие партии должно быть тривиальным.

Независимо от этого, вы можете определить службу, которая принимает транзакции в пакетном режиме и отвечать с кодом состояния HTTP «Принято 202». Код 202 указывает, что запрос был получен и будет обрабатываться асинхронно. Таким образом, ответ может также содержать ссылки обратного вызова для проверки состояния отдельных транзакций; или партии в целом. В этот момент вы будете внедрять HATEOAS (Hypermedia как механизм состояния приложения) и быть в состоянии автоматизировать весь процесс и сообщать о статусе.

Исправлено с пакетными файлами, если файл проходит проверку подлинности переднего формата, вам все равно придется обрабатывать каждую транзакцию отдельно по течению. Некоторые записи могут загружаться, другие - нет. Мое предположение - это записи, которые не загружаются, все равно нужно будет обрабатывать. И вам может потребоваться предоставить пользователям представление о том, что удалось или нет. Теперь все это можно обработать вне REST API. Тем не менее, шаблон API простой и элегантный IMHO для этой цели.