Построение API

[Mortimoro]

Появилась необходимость построения API, но так как раньше с реализацией подобных вещей не сталкивался, решил проконсультироваться...

Что хотят от меня: наши реселлеры хотят получать актуальную информацию о наших товарах и действующих акциях, чтобы отображать ее на своих сайтах. Эта информация у нас обновляется непериодично, то есть может пару дней не обновляться, а потом обновиться раз 5-7 за день. Так же и новости с сайта - они могут неделю не добавляться, затем сразу 2-3 новости, которые реселлеры так же хотят отображать на своем сайте.

Что хочу я:
1.минимальную нагрузку на сервер и канал - это в первую очередь, ибо данная фича больше нужна реселлерам, чем нам самим, и если они будут создавать нам проблемы, то от этого шага навстречу придется отказаться.
2.удобство и простота использования для программистов разного уровня (у реселлеров есть и профессионалы, и студенты-самоучки). Если отказаться от этого пункта, то я мог бы просто скинуть всю инфу в текстовые файлы без всяких API и пусть скачивают/парсят кто как умеет, но хорошими словами меня никто после этого не назовет.

Собственно вопрос: Как грамотно и красиво это реализовать? Как должен выглядеть API, чтобы вам лично было приятно с ним работать, если один из реселлеров закажет у вас инсталляцию модуля на свой сайт?

[zumm]

Хм. Ну на самом деле это задача не пыльная. Главное продумать какие могут понадобиться базовые методы и реализовать их с поддержкой ответов (и, опционально, запросов) в разных форматах. JSON, XML, как минимум. Для экономии на спичках и парсинге также возможен text/plain. Вот и все. Если пользователям будет чего-то не хватать, то они вам об этом скажут.

[Mortimoro]

то есть каких-либо четких стандартов придерживаться незачем? разработать свой интерфейс взаимодействия и все?

[Johnatan]

При непериодическом обновлении информации, вы сами можете инициировать соединение с реселлерами, а не они должны каждые 5 минут долбиться к вам на сервер в ожидании получить сладкое. Это позволяет снизить нагрузку на ваш сервер.

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

Плюсы: моментальная передача реселлеру свежей информации, малая нагрузка на сервер, минимум кода с вашей стороны.
Важный минус - возможность утери информации. Например, если сервер реселлера недоступен в момент инциирования соединения, то он не получит текущую информацию, а возможности перезапросить эту информацию у него нет.

Либо стандартная схема REST-API. Когда клиенты(реселлеры) периодически стучатся к вашему серверу и требуют свежей информации.

[Mortimoro]

Johnatan, благодарю! Я как раз вчера пришел именно к такому варианту - стучаться к реселлерам по мере необходимости. Чтобы избежать утери информации с моей стороны, я буду ждать от реселлера ответ и через 5 минут после отправки повторять отправку тем, от кого ответ не пришел, снова ожидая ответа... третья попытка еще через 15 минут и хватит - если сервер реселлера 20 минут не принимает информацию, значит у них проблема посерьезнее, чем неполучение моей информации. Меня больше беспокоит другой минус данного подхода - реселлер вынужден хранить эту информацию у себя, а так как у многих не профессиональные программисты работают, а говнокодеры, придется еще и модуль обработки информации для них писать, а потом помогать устанавливать, объяснять принцип работы и т.п. со всеми вытекающими. Потому, пока что я все же склоняюсь к стандартной схеме, ибо проще объяснить программисту реселлера, что это его проблемы, что он не знает как работать с API, чем выяснять почему у него не работает написанный мной модуль.

Про REST я читал - несмотря на то, что это стандарт и он во многом удобен, его не очень хвалят за громоздкость. К тому же, как я выяснил, большинство программеров не смущает разнообразие API и методов исполнения, лишь бы мануал был... потому я колебаюсь между лаконичной простотой и стремлением к общепринятым нормам и стандартам.

[Johnatan]

Так, давай отделим мух от котлет.
Реселлеры в ЛЮБОМ случае должны будут хранить твою информацию у себя. Будь то в кеше, будь то в базе, да хоть в текстовых файлах. Иначе какой смысл передачи информации, если она теряется сразу после закрытия соединения?

Я почти уверен, что у каждого реселлера свой онлайн магазин/склад/блэкджек с дамами. Ты каждому отдельно модуль собираешься писать? Твоя задача сделать надёжный и правильный способ передачи информации. Кто и за какие деньги будет реализовывать клиентскую часть - вопрос отдельный. Ты же сам чётко дал понять, что эту систему хотят реселлеры. Ну так пускай всё делают правильно. Говнокодеры на другом конце тебя волновать не должны.

Все эти попытки каждые 5 минут передать информацию - это неправильно. Правильно, это когда приложение реселлера стучится к тебе, например, один раз в сутки и сообщает, что оно "живое". А ещё лучше, если оно раз в сутки сообщает тебе новый API ключ с которым ты должен передавать ему информацию. Ведь мы же понимаем, что завтра прийдёт школьник Вася и под видом тебя передаст твоему реселлеру ложную информацию просто для фана или может даже за денюжку. API должно быть безопасным.

Итого схема такая:
1) Создаёшь у себя в базе нового реселлера, задаёшь ему точку входа и некий СВОЙ API-ключ.
2) Ручками или мылом передаёшь реселлеру этот API-ключ и СВОЮ точку входа, куда реселлер должен будет стучаться, например, раз в сутки.
3) Реселлер стучится к тебе раз в сутки и передаёт этот (ТВОЙ) ключ как пароль, а также передаёт СВОЙ API-ключ, с которым позже ты будешь стучаться к реселлеру.
3-а) Твой сервер генерирует НОВЫЙ API ключ (новый пароль) для реселлера и передаёт ему этот ключ в ответ на его запрос, а также сохраняет у себя тот ключ, что он тебе дал.
3-б) Твой сервер проверяет, отсылалась ли этому реселлеру вся последняя информация. Если есть информация, которая не была отослана реселлеру (реселлер был недоступен или реселлер ещё никогда не получал информацию от тебя), то передача информации заносится в очередь.
4) Твой сервер получает сигнал, что нужно передать информацию реселлеру. Он открывает соединение и передаёт реселлеру тот API ключ, который реселлер раз в сутки передаёт тебе. Происходит авторизация. После авторизации твой сервер отсылает всё что нужно реселлеру.
4-а) Если сервер недоступен, или авторизация не прошла успешно, или метеорит упал на твоего реселлера, то ты больше не соединяешься с реселлером. Информация просто НЕ помечается как отосланная именно этому реселлеру.
Дальше переходим к пункту 3). Если у реселлера "падал" сервер, то он может сразу же стукнуться к тебе за новым API паролем, что в свою очередь сразу запустит систему передачи неотосланной информации реселлеру.

Всё. Минимум нагрузки на серверы. Максимум безопасности и стабильности.


P.S. REST не громоздкий. REST просто правильный и логичный. Но это не обязательная технология. Просто раз уж делать правильно, то стóит правильно делать всё.

[Mortimoro]

Хмм... гениально! Жаль, что стоит лимит на добавление тебе репы ))

Мне такой вариант подходит, потому за основу его и возьму. Благодарю!