rPman

ваша crm готова к нагрузке, которую будет генерировать веб сайт?

если ты будешь выгружать данные, значит тебе придется следить за их актуальностью

выгруженные данные это кеш оригинальных данных, в принципе можно совместить подход, работать с api но обеспечить механизм хранения (в т.ч. заранее загруженых) копии данных в базе веб сервера, дополнив api crm инструментами по оповещению об изменении и обновлению этих данных.

p.s. мне нравится варианты построения на основе master-slave репликация базы crm средствами sql базы данных, все изменения будут оперативно (с очень минимальным лагом) заливаться в slave-реплику базы, и вот уже с ней может спокойно работать веб сервер как со своей, на чтение

--get --data-urlencode page=1

Тебе нужен не api к трекеру, а точная и качественная база торрент с безглючной связью с базой например кинопоиска.

Я такого не видел, если найдешь отпишись тут.

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

Торент - это больше не хранилище данных (беда технологии, так как нет механизмов управления того какие торенты у клиентов должны храниться а какие удаляться, например редкие и наоборот слишком популярные) а некий оперативный буфер для контента здесь и сейчас, очень хорошо справляется когда сразу куча людей начинают что то скачивать но плохо с хранением на долго, особенно чего то не популярного. Отсюда народ не видит смысла правильно оформлять контент, например с обязательной ссылкой на кинопоиск/imdb и машиночитаемое описание с тегами по жанрам, авторам и т.п. чтобы поиск работал, и главное этот процесс сложно монетизировать и поддерживать в долгую.

Идеологически верное решение - установить Litecoin кошелек (чтобы не занимал много места, кажется до 500мб, нужно использовать опцию -prune=макс_размер_блокчейна_в_мб).

с помощью ключа командной строки
-walletnotify=<cmd>
можно принимать алерты об изменениях на балансе

с помощью rpc команд (примеры смотри у bitcoin так как litecoin почти идентичный его форк) делать запрос о конкретике, например создании адреса для приема монет, балансе адреса, создании новой транзакции или о количестве подтверждений

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

Причина - защита основного баланса при взломе веб-сервера.

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

Любые исходящие транзакции только на заранее определенный список адресов, если же нужно отправлять деньги пользователю, то добавление нового адреса и суммы для вывода на него должны проходить дополнительный аудит.

Когда то, там где это было не критично, бакэенд я делал в виде примитивной прослойки для базы данных и хранения sql запросов, т.е. клиент в запросе выдавал идентификатор запроса и список его параметров именованным массивом, а сервер возвращал табличку как есть, код на php чуть ли не десяток строчек плюс список sql запросов. Если запросов за раз бывает много, ввести возможность отправки их пакетом....

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

мне кажется coinkeeper берет данные из sms у них в описании это и написано а еще туда можно вручную заводить транзакции

p.s. доступ к api юрикам банки дают, за отдельные деньги и отдельным договором

Единственный самый дешевый 'api, доступный частникам', это мобильный банк сбербанка (50р в месяц). Т.е. буквально ставишь модем и пилишь отсылку sms на номер 900 (кстати может тарифицироваться как обычные sms, например 1.8р за сообщение но это уже смотреть тариф ОПСОСа), там куча операций, начиная с пополнения мобильных счетов, денежных переводов и кончая коммунальными платежами (меньше список чем тот что доступен в сбербанк онлайн, так как если я верно понимаю, за это сберу коммунальщики должны дополнительно отстегивать или еще какие условия).

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

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

тебе нужна key-value база данных, если данных мало и они влезают в память массивом $index[$hash]=true то тогда храни в файле в сериализованном виде var_export/serialize/json_encode или даже по 1 строке на запись - читать array_flip(file('имя файла'))

p.s. бери sqlite, на столько простой удобной и неприхотливой базы данных не найти, реализованна в файле, ничего не требует для администрирования, работает везде...

Первый же результат в гугле, на javascript для imgbb, пишут что работает

там же такой простой api что не так то?

p.s. про http забудь, этот протокол умрет как гопер или фтп, проблем он создает столько что лучше его не поддерживать принципиально

В общем случае никак.

Иногда может помочь грамотное логирование ответов об ошибках, а так, только следить за официальными блогами/твиттерами/отчетами или даже github проектов.

p.s. правильный сервис не должен менять api на ходу, а при необходимости создается новая версия с продолжением поддержки старой либо сыпать ошибками, если это невозможно.

видео:
не api но консольная утилита, youtube-dl кажется одна из лучших, качает с youtube, vimeo, и туева кучи сайтов, обновляется оперативно под изменения форматов.