Организация API для сторонних приложений: какие технологии?

← →
ksergey © (2015-10-23 12:54) [0]

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

Платформа - только Windows.

Вопрос: какие нынче технологии есть вообще и в в тренде для таких дел? хотелось бы обеспечить возможность подключаться из более-менее разных приложений: VB, Delphi, java-script быть может(имеется ввиду скрипты, выполняемые "внутри Windows", не WEB-технологии), C#.
Нужны просто ключевые слова.

Что знаю я, для примера:
1) Можно вытащить COM-интерфейс
2) Можно сделать DLL, которую пользователь будет подгружать в своё приложение и дёргать из неё функции - а эта DLL как-то будет взаимодействовать с основной программой
3) Можно взаимодействовать через какую-то БД, например (а что, вариант)
ну и т.п.

Какие еще есть варианты, достаточно удобные для использующих это API?

Я слышал слова SOAP - это оно?

← →
DayGaykin © (2015-10-23 13:08) [1]

Если только Windows, то Com. Еще и в виде ActiveX компонента оформить.

← →
Кто б сомневался © (2015-10-23 13:09) [2]

Вам ехать надо или шашечки?

> какие нынче технологии есть вообще и в в тренде для таких
> дел?

В тренде нынче сделать готовый продукт, удобный, без багов и быстро работающий.

← →
Кто б сомневался © (2015-10-23 13:13) [3]

Обычно это делают через плагины dll. А внутри dll - или классические вызовы или через interface.

← →
Кто б сомневался © (2015-10-23 13:29) [4]

Можно попробовать сделать плагин для тотал командера, чтоб понять детали.
К примеру http://www.ghisler.com/plugins.htm - под каждой таблицей есть хелп файлы - с деталями того, как делать плагин - WCX Plugin Guide, FS Plugin Guide итд.
В ТС кстати классические процедурные вызовы dll.

← →
ksergey © (2015-10-23 13:53) [5]

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

← →
Кто б сомневался © (2015-10-23 14:42) [6]

> Но задачи именно предоставить удобный API для внешних приложений.

Что означает "API для внешних приложений"?

Тут все зависит от задачи, смотря чем они обмениваются, может вообще будет достаточно обычных WM сообщений (втч broadcast сообщений) или отображенного в память файла (Memory Mapped Files) со своими структурами.

← →
Кто б сомневался © (2015-10-23 14:52) [7]

Давайте попросим в студию ИШ, который помог бы "стеснительно" задать один важный вопрос.

← →
Игорь Шевченко © (2015-10-23 15:19) [8]

ksergey © (23.10.15 12:54)

Я бы COM-интерфейс сделал.

← →
ksergey © (2015-10-23 15:58) [9]

> может вообще будет достаточно обычных WM сообщений

На vbs? привычная ли и удобная ли это техника для программиста vbs?

Еще раз.
Хотелось бы услышать слова, которыми пользуются нынче люди для организации API в своих приложениях для доступа из других приложений (получение/отправка данных по сути). Причем данные не потоковые. Друбо говоря методы GetЧтоНибудь() SetЧтоНибудь()

Или даже так: в промышленных продуктах (промышленно-количественно используемых) какие нынче делают API для доступа внешних программ?
Просто так получается, что много WEB-а на слуху, а вот если не про WEB - то что? понимаю, что можно взять и посмотреть какой API есть, но вдруг будут готовые ответы. На это лишь и уповаю.

← →
KSergey © (2015-10-23 15:59) [10]

>Игорь Шевченко © (23.10.15 15:19) [8]
> Я бы COM-интерфейс сделал.

Эх, я вот тоже пока вижу в этом наиболее универсальный вариант.
А моднее и может быть проще - ничего нет, случайно?

← →
картман © (2015-10-23 16:44) [11]

> ksergey © (23.10.15 15:58) [9]

хватит балду пинать, начинай уже работать

← →
ksergey © (2015-10-23 16:54) [12]

> хватит балду пинать, начинай уже работать

/* испуганно озираясь */
кто ты??

← →
Кто б сомневался © (2015-10-23 17:45) [13]

> > может вообще будет достаточно обычных WM сообщений
>
> На vbs? привычная ли и удобная ли это техника для программиста
> vbs?

Нет, vbs как раз использует только COM (по факту это dll"ки) и ничего больше.

> ksergey © (23.10.15 16:54) [12]
>
> > хватит балду пинать, начинай уже работать
>
> /* испуганно озираясь */
> кто ты??

Это твое вдохновение.

// А фраза "кто ты?" у меня в голове воспроизвелась голосом А Ревы. :)

← →
кгшзх © (2015-10-23 18:22) [14]

вебсервис однозначно

← →
Dimka Maslov © (2015-10-23 19:48) [15]

> Я бы COM-интерфейс сделал.

И я бы сделал COM интерфейс. Просто и универсально. При правльной организации для два щелчка прикручивается к чему угодно.

← →
Eraser © (2015-10-24 00:20) [16]

> ksergey © (23.10.15 12:54)

если нужно модно, то вроде REST.

> Платформа - только Windows.

я бы не зарекался. попросят мобильную версию )

← →
ksergey © (2015-10-24 17:08) [17]

> Eraser © (24.10.15 00:20) [16]
> я бы не зарекался. попросят мобильную версию )

В данном случае нет )

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

← →
KSergey © (2015-10-24 17:08) [18]

Большое спасибо всем за мнения и слова!

← →
KSergey © (2015-10-24 17:12) [19]

Кстати, про COM
Использовать-то я его использовал из разных мест - это клёво, в самом деле очень удобно и просто, а вот делать ни в жисть не доводилось, есть такой пробел у меня серьёзный.
От того и пытаюсь что-то выдумать.

Вот бы почитать как люди собственно COM-сервера делают, на какие соображения при этом ориентируются. С учётом постоянного расширения интерфейса (это точно будет).

> Вот бы почитать как люди собственно COM-сервера делают

https://www.google.ru/search?q=Delphi+%D1%81%D0%BE%D0%B7%D0%B4%D0%B0%D0%BD%D0%B8%D0%B5+COM+%D1%81%D0%B5%D1%80%D0%B2%D0%B5%D1%80%D0%B0&ie=utf-8&oe=utf-8&gws_rd=cr&ei=1ZgrVo_SCaLgyQPytZPgCA

> Вот бы почитать как люди собственно COM-сервера делают,

Есть книжка: Елманова,Трепалин,Тенцер - Delphi и технология COM , 2003
djvu

У меня эта книжка есть в печатном виде.
ниасилил )

Ну и потом, вопросы как таковой техники -они, понятно, решаемы. Меня волнует другое: как потом это всё поддерживать и развивать, на сколько удобно. Этот бы момент почитать концентрированно, "опыт эксплуатации и развития СОМ-сервера", так сказать.

> ksergey © (24.10.15 18:15) [23]
> на сколько удобно.

Правильнее, конечно, сказать так: о чем надо думать при развитии интерфейса.

> Юрий Зотов © (24.10.15 17:44) [21]

Я понимаю, что форум про дельфи, но речь не про дельфи в данном случае. Хотя это опять же детали, конечно, можно любое другое слово подставить в запрос.

> "опыт эксплуатации и развития СОМ-сервера", так сказать.

Because in-process COM components are implemented in DLL files and registration only allows for a single version of a DLL per CLSID they might in some situations be subject to the "DLL Hell" effect. Registration-free COM capability eliminates this problem.

>ksergey © (24.10.15 18:15) [23]
> Меня волнует другое: как потом это всё поддерживать и развивать, на сколько удобно. Этот бы момент почитать концентрированно, "опыт эксплуатации и развития СОМ-сервера", так сказать.

поддерживаю такой проект трехзвенку

любой кривой компонент с утечкой памяти на клиенской части и catastrofic failure (примерно так)

не просто отлавливать ошибки (где ole а где дельфовские)

все построено на транзакциях

Организация API для сторонних приложений: какие технологии? Найти похожие ветки