Преобразование и унификация данных API в Python

Я пытаюсь извлечь аналогичные данные из нескольких сторонних API, каждый из которых имеет несколько различающиеся схемы, и преобразовать их все в единую схему для хранения в БД и предоставления доступа через унифицированный API. На самом деле это переписывание системы, которая уже делает это, за вычетом хранения в БД, но которую трудно тестировать и она не очень элегантна. Я решил обратиться к сообществу за некоторой мудростью. Вот некоторые мысли / чего я хотел бы достичь.

  • Простой способ указать сопоставления схемы из схемы внешнего API во внутреннюю схему. Я понимаю, что некоторые нюансы в данных могут быть потеряны при преобразовании в унифицированную схему, но такова жизнь. Это отображение схемы может быть непростым и, возможно, излишним из академических статей, которые я нашел по этому вопросу.
  • Альтернативным решением было бы позволить третьим сторонам разрабатывать интерфейсы для внешних API. Качество кода этих третьих сторон может быть известно или неизвестно, но может быть установлено с помощью тщательных тестов.
  • Поэтому систему должно быть легко тестировать, я думаю, имитируя внешние вызовы API, чтобы иметь воспроизводимые данные и гарантировать, что синтаксический анализ и преобразование выполняются правильно.
  • Падение одного из внешних API-интерфейсов не должно приводить к падению остальных.
  • Какая-то проверка схемы/способ определить, изменились ли внешние схемы API без предупреждения
  • В конечном итоге это будет интегрировано в проект Django, поэтому его можно будет написать как приложение Django, что, вероятно, упростит модульное и интеграционное тестирование. С другой стороны, я хотел бы, чтобы он был максимально отделен от Django. Хотя интерфейсы API должны знать, в какой формат конвертировать, можно ли это указать во время выполнения?

Я что-то пропустил в списке желаний? Нереально? Пошли по ложному пути? Хотелось бы получить обратную связь.

Я не уверен, есть ли проекты библиотек/ОС, которые уже делают что-то из этого. Чем меньше колес мне придется изобретать, тем лучше. Будет ли какая-то часть этого ценна как проект ОС?

В предыдущей версии я породил кучу потоков, которые обрабатывали бы отдельные запросы. Хотя я никогда не использовал его, мне сказали, что я должен смотреть на gevent как на способ справиться с этим.


person Andres    schedule 05.04.2013    source источник
comment
Это кажется слишком широким для SO.   -  person tacaswell    schedule 05.04.2013
comment
@tcaswell Я мог бы разбить его на более мелкие куски, но они, вероятно, не имели бы смысла сами по себе   -  person Andres    schedule 05.04.2013


Ответы (1)


Для второго пункта вам следует посетить Temboo. Temboo нормализует доступ к более чем 100 API, а это означает, что вы можете общаться с ними всеми, используя общий синтаксис на выбранном вами языке. В этом случае вы должны использовать Temboo Python SDK, доступный здесь.

(Полное раскрытие: я работаю в Temboo)

person Cormac Driver    schedule 05.04.2013
comment
Спасибо, но я не нашел ни одного из API, которые планировал использовать. Однако было бы полезно, если бы вы могли рассказать, как вы взаимодействуете с ними. - person Andres; 05.04.2013
comment
Конечно. Короче говоря, мы создаем процесс для каждого вызова API, что позволяет нам абстрагироваться от различий, которые вы найдете в отдельных API, и предоставить нашим пользователям единый интерфейс для огромного количества API. Затем наши SDK вызывают эти процессы, которые, в свою очередь, взаимодействуют с базовыми API. Этот уровень косвенности позволяет нам делать такие вещи, как преобразование формата ответа и более удобную обработку/отчетность об ошибках, что делает работу с API более приятной. - person Cormac Driver; 05.04.2013