Comments 22
Это просто нереально круто! Вопрос к разработчикам API — действительно использование API никак не ограничено? У меня есть конкретный use case, где мне нужно показывать посетителям переводы слов. Могу ли я использовать ваш API для этой цели?
Какая лицензия на изображения к словам?
Какая лицензия на изображения к словам?
Действительно никаких ограничений на использование API нет, кроме общечеловеческих, типа не ронять наши сервера. Мы предоставляем API как есть без каких-либо гарантий. Ну и вы сами несете ответственность за соблюдение законов и авторских прав при его использовании.
По первому пункту понятно. А что касается авторских прав — кто является владельцем переводов, озвучек и изображений? Если это не Skyeng, то какие лицензионные ограничения распространяются на третьих лиц?
В данный момент мы не готовы ответить на этот вопрос, т.к. юристы готовят лицензионное соглашение, которое полностью покроет все правовые вопросы по всему контенту, часть которого произведена нами, часть куплена, чаcть — public domain с разными формами лицензирования; это долгий процесс, поэтому мы даже сроков конкурса пока не называем. Мы написали статью и открыли доступ для того, чтобы все желающие могли посмотреть, разобраться и научиться пользоваться. Если вы уже прямо сейчас хотите выкатить что-то коммерческое — пожалуйста, свяжитесь с нами через «Заявку», мы попробуем сориентировать по срокам.
Супер, спасибо за ответ! Было бы здорово сделать email-рассылку, чтобы можно было оперативно получать все новости API.
Сам интерфейс действительно очень востребован, т.к. у небольших проектов и стартапов нет доступа к базовому языковому контенту, как, например, словарь. И это стопорит многие хорошие идеи.
Сам интерфейс действительно очень востребован, т.к. у небольших проектов и стартапов нет доступа к базовому языковому контенту, как, например, словарь. И это стопорит многие хорошие идеи.
Привет, Skyeng. Люблю вас и рад запуску API. Но вы вместе с ним вываливаете в паблик списки всех слов, которые учат ваши пользователи. В частности, я обнаружил там свои. Вы уверены, что поступаете правильно, сливая в публичный доступ информацию, которую пользователь, вероятно, не хотел бы раскрывать (и уж точно он не знал, что так будет сделано)?
«vimbox Субтитры» — вот почему 25 июня закрывается один, очень удобный проект?
В ответе api урлы картинок относительные. Какой префикс добавлять?
Изображения достаточно быстро отдаются. Причём необходимых размеров для моего приложения, то есть на слой кеширования, на начальном этапе можно не заморачиватся.
Интересно было бы узнать архитектуру, если это самописное решение:
— чем режете?
— как организовываете кеширование(если есть)?
— какой мощности сервер для нарезки?
<img src="http://static.skyeng.ru/image/download/project/dictionary/id/5702/width/2710/height/2710"/>
<img src="http://static.skyeng.ru/image/download/project/dictionary/id/5702/width/2810/height/2810"/>
<img src="http://static.skyeng.ru/image/download/project/dictionary/id/5702/width/2910/height/2910"/>
Интересно было бы узнать архитектуру, если это самописное решение:
— чем режете?
— как организовываете кеширование(если есть)?
— какой мощности сервер для нарезки?
Да, это самописное решение. Точнее, это даже не проектировалось как цельное решение, просто у нас накопилось довольно много логики для работы с изображениями, поэтому мы вытащили это из других сервисов и положили под api.
Как и большинство наших приложений, это тоже написано на php, вся обработка ведётся стандартными средствами gd.
Текущая логика работы с производными форматами это не кэш в полноценном смысле, потому что автоматической инвалидации нет, мы храним все сгенерированные картинки производных форматов. Это решение хорошо подходит для нашего внутреннего использования, так как у нас относительно небольшое количество вариантов использования конкретной картинки. Для массового использования извне всё уже не так радужно, поэтому если будут проблемы, нам придётся поменять логику.
Сейчас ведутся изменения в инфраструктуре, текущей сервер не загружен, поэтому показательных конфигураций я не приведу. Но могу сказать, что относительно остальных ресурсов первое, что будет ограничивать — это сеть фронтенда, с которого всё раздаётся.
Из вашего комментария не понятно, но если имеется в виду мобильное приложение, то клиентским кэшированием озаботиться всё же стоит, без него ограниченная скорость мобильной сети сильно портит ux. Ну и мы будем рады, если наш канал не будет забиваться зря)
Как и большинство наших приложений, это тоже написано на php, вся обработка ведётся стандартными средствами gd.
Текущая логика работы с производными форматами это не кэш в полноценном смысле, потому что автоматической инвалидации нет, мы храним все сгенерированные картинки производных форматов. Это решение хорошо подходит для нашего внутреннего использования, так как у нас относительно небольшое количество вариантов использования конкретной картинки. Для массового использования извне всё уже не так радужно, поэтому если будут проблемы, нам придётся поменять логику.
Сейчас ведутся изменения в инфраструктуре, текущей сервер не загружен, поэтому показательных конфигураций я не приведу. Но могу сказать, что относительно остальных ресурсов первое, что будет ограничивать — это сеть фронтенда, с которого всё раздаётся.
Из вашего комментария не понятно, но если имеется в виду мобильное приложение, то клиентским кэшированием озаботиться всё же стоит, без него ограниченная скорость мобильной сети сильно портит ux. Ну и мы будем рады, если наш канал не будет забиваться зря)
Из вашего комментария не понятно, но если имеется в виду мобильное приложение, то клиентским кэшированием озаботиться всё же стоит, без него ограниченная скорость мобильной сети сильно портит ux.
для аудио также придётся пробовать писать кеш слой…
http://static.skyeng.ru/audio/download/project/dictionary/id/YToyOntpOjA7czo2OiJzdGF0aWMiO2k6MTtzOjQzOiIvYXVkaW8vMjQyZTczYzZkMDA2ZmU4ZjliNjlkNTBjODhkNDFjMDgubXAzIjt9
— А есть возможность использовать женский голос в озвучке?
— И тот же вопрос — чем генерируете аудио?
А что на счёт синонимов? Планируете добавлять в API?
Странно, но результаты зависят от регистра слова?
Вот пример:
dictionary.skyeng.ru/api/public/v1/words/search?search=bear
dictionary.skyeng.ru/api/public/v1/words/search?search=Bear
Два разных результата (если опираться на то, что первый элемент массива должен быть максимально точен к запросу). Это конечно поправимо на стороне приложения, но все же.
Вот пример:
dictionary.skyeng.ru/api/public/v1/words/search?search=bear
dictionary.skyeng.ru/api/public/v1/words/search?search=Bear
Два разных результата (если опираться на то, что первый элемент массива должен быть максимально точен к запросу). Это конечно поправимо на стороне приложения, но все же.
Есть ли в планах открывать больше методов/информации?
Например,
1) в words.skyeng.ru/api/public/v1/users/meanings нет даже указания групп, в которых находятся мои слова
2) words.skyeng.ru/api/public/v1/words, как я понимаю, позволяет добавлять новые слова. Но опять же в какую группу они добавятся? Хотелось бы иметь возможность задавать это.
Еще хотелось бы конечно описания, как изменяется значение progress.
Например,
1) в words.skyeng.ru/api/public/v1/users/meanings нет даже указания групп, в которых находятся мои слова
2) words.skyeng.ru/api/public/v1/words, как я понимаю, позволяет добавлять новые слова. Но опять же в какую группу они добавятся? Хотелось бы иметь возможность задавать это.
Еще хотелось бы конечно описания, как изменяется значение progress.
Да, в планах есть, мы собираем пожелания от конкурсантов и партнеров. К сожалению, у этой задачи пока не самый высокий приоритет, но, думаю, к следующему конкурсу методов и возможностей добавится. В том числе и Ваши 1) и 2).
1) сейчас берутся все слова из всех наборов. Очевидно, что с ростом числа внешних приложений будет необходимо добавить возможность видеть наборы и брать слова не из всех.
2) слова добавляются в набор «Внешние приложения». Я думаю, мы сделаем «полу-открытый» метод API для создания наборов, который будем давать сторонним разработчикам, которым он действительно нужен. Пока мало кто пользуется возможностью добавлять слова.
1) сейчас берутся все слова из всех наборов. Очевидно, что с ростом числа внешних приложений будет необходимо добавить возможность видеть наборы и брать слова не из всех.
2) слова добавляются в набор «Внешние приложения». Я думаю, мы сделаем «полу-открытый» метод API для создания наборов, который будем давать сторонним разработчикам, которым он действительно нужен. Пока мало кто пользуется возможностью добавлять слова.
Sign up to leave a comment.
Экосистема: больше участников — больше прибыль! Зачем Skyeng открывает API