×Закрыть

Стартап: API aggregator + end-user recipes. Шукаємо JS програмістів

Зараз є багато сервісів (Facebook, Twitter та інші), які мають відкритий REST API. З іншого боку юзери хочуть отримувати дані з цих сервісів, тому зараз почало з’являтись багато платформ (наприклад dashboards: cyfe.com, ducksboard.com; плагіни для електронних таблиць: supermetrics.com, spreadsheetbooster.com; app-automating services: ifttt.com, zapier.com; та інші). Їх всіх об’єднує те, що вони дають можливість отримувати дані з різних сервісів, використовуючи зрозумілі кінцевому користувачу рецепти (метрики, тригери, parameterized queries). Їх спільною проблемою є складність додавання нових сервісів та рецептів.

Ми вирішуємо цю проблему для платформ, збираючи machine-readable описи REST API, підтримуємо їх в актуальному стані та створюємо зручні для кінцевого користувача рецепти (JS snippets) на основі API одного або декількох сервісів. Ми надаємо достатньо детальні описи API і рецептів, для того щоб згенерувати повноцінний UI (names, types, descriptions, help messages, etc).

Хочем працювати по моделі BaaS. Монетизація: % від продажу платних API вроздріб, доступ до описів та рецептів по моделі Wikipedia. За можливості будемо робити все open source.

Зараз на стадії розробки MVP, шукаємо JS програмістів для розробки back end і частково front end.

Email: info@apis.guru

LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Впринципі ідея цікава. Можливо має право на життя. Якщо буде дійсно велика і актуальна база апі. Єдине прикидуючи який там об’єм робіт незнаю чи вам вийде зроботи дійсно якісний продукт без фінансування.

Відсутність грошей робить людей креативними :)
В нас є ідеї як зробити збір описів напів-автоматичним(~20% manual) а в деяких випадках навіть автоматичним. Наразі закінчуємо підключення всіх сервісів Google. Плюс на протязі кількох місяців повинні отримати 700+ описів від людини яка цим займається незалежно від нас.

Кінцевим споживачем сервісу будуть програмісти? Чи ви якось хочете це продавати звичайним юзерам, які не розуміють, що таке API?

Наразі робоча модель це продавати платформам(dashboards, spreadsheet, ...), щоб вже вони займались генерацією UI а ми виступали більше як back end.

щось я не зашарив цілі стартапу.
людей які реально будуть користоватися АРІ до сервісів вже одиниці.
це не є достатня таргет-одієнс

імхо якщо вже щось робити то кінцевий продукт а не напівфабрикат.
Наприклад систему на основі алгоритму, що сам автоматично шукає соц мережі по інету та їх АРІ, потім агрегує до себе.
Тобто є агрегатором соц мереж, де в одній «лєнті» є новини і з фейсбука і з вконтакті і з лінкедіна і з твіттера і з тонни інших сайтів/мереж по вибору користовача. При чому погрупповані по категоріям щоб можно було порівняти що про те саме пишуть на різних мережах різні люди.

Ну і подавати це у вигляді готової проги під яос і ведроїд.

Отаке є шанс продати з виграшем.

автоматично шукає соц мережі по інету та їх АРІ
Це вже якийсь штучний інтелект. Я слабо уявляю як можна автоматично розпізнати що це API саме соціальної мережі.
Тобто є агрегатором соц мереж, де в одній «лєнті» є новини і з фейсбука і з вконтакті і з лінкедіна і з твіттера
Оце якраз можливо, але тяне на окремий стартап.
Отаке є шанс продати з виграшем.
Ми хочемо спробувати свої сили на B2B ринку а не B2C. Тому зрозуміло що ми не робимо аплікухи під телефон і массовий користувач нас не побачить. А от наскільки ми цікаві на B2B ринку ми зараз виясняємо, в переписці з потенційними клієнтами.

условно рабочая бизнес модель www.mashape.com

Про них знали з самого початку. Принцип інший, вони не дають способу отримати machine-readable описи, а це основна віча нащої ідеї. Плюс їх таргет аудіторія трохи інша девелопери які купляють підписки на API.
Якщо вже розглядати конкурентів то webshell.io набагато ближче, але всеодно не те.
Наша ціль дозволити клієнту генерувати UI заточенний під звичайного користувача.

Я сомневаюсь, что вы найдете даже одного клиента, готового заплатить вам:
1) Любой API гуглится за пару минут.
2) Все API сразу никому не нужны
3) На сайте нужного мне сервиса, всегда будет самое актуальное описание
4) Сервисы часто предоставляют и клиентские библиотеки к своим API. Зачем мне читать инфу про API на вашем сервисе, когда мне все равно прдется искать клиентскую библиотеку у них на сайте?
5) Когда компания предоставляет API, у нее часто есть форум, где можно обсудить проблемы/нюансы работы этого API.
6) Любые ваши клиентские библиотеки добрые люди выложат на гитхаб, поэтому заработать на их продаже тоже не удастся.

P.S.
Я думаю, что аналогичных сервисов десятки и они все умирают или умерли, т.к. а) не нужны, б) не могут заработать денег.

Ваші аргументи дійсно мають сенс якщо б ми займались збором human-readable описів API. Але machine-readable то вже зовсім інша історія, наприклад це опис тестового REST API: github.com/...ore_simple.yaml а ось вже UI petstore.swagger.io згенерованний на основі нього з підтримкою викликів, валідації і навіть Oath. А тепер подивіться на UI одного з плагінів для spreadsheet booster-booster.s3.amazonaws.com/...ster-demo-2.gif
Між двома UI багато схожого, бо то звичайні обгортки навколо API. Різниця в тому що перший згенерованний а другий написанний.
Тепер підемо далі, користувач заходить в такий плагін і намагається знайти там необхідний йому сервіс. Потім стає ще цікавіше, він хоче не просто якусь метрику під цей сервіс, а він хоче саме ту метрику яка йому цікава. Якщо не знаходить, то просто не купляє або йде до конкурентів і перевіряє чи вони таке підтримують.
Ми вірушуємо таку проблему надаючи власні REST API через які наш клієнт може витянути machine-readable(для UI) опис метрики і JS код який робить виклики. Маючи такі API плагін може згенерувати повноцінний UI, і користувач отримує доступ до всіх метрик які ми супортаємо.
Це тільки один приклад клієнта, ми не зациклюємось на spreadsheet і метриках.

так, JS snippets нікому не продаси, а ось можливість отримати дані з API в таблицю, до якої звикли користувачі не програмісти — було б цікаво

Подписаться на комментарии