Pull to refresh
3
0
Роман Лукьяненко @lukianenko

специалист по системам IP телефонии

Send message
Отличное решение! Удачи вам в развитии данного продукта, обязательно буду следить за вашим блогом!
Вам спасибо за статью, очень интересно почитать!
«данные примерно 3500 тысяч клиентов» — как то не по русски :) может всё же стоило написать 3,5 миллионов?
1. Мы сознательно отказались в своем API от использования любых методов, кроме GET и POST, чтобы избежать возможных проблем. Дискуссию на эту тему можно посмотреть здесь. Если вкратце, то может случиться ситуация, когда криво настроенный прокси-сервер проглотит методы типа PUT или DELETE (http://habrahabr.ru/post/181988/#comment_6366880).
Или попадется клиент, который кроме GET и POST, ничего посылать не умеет (http://habrahabr.ru/post/181988/#comment_6369042).
Прецеденты уже были: http://stackoverflow.com/questions/2061898/urlrequest-with-delete-method

2. По поводу статуса — это сделано больше для наглядности, чтобы можно было оценить результат запроса без обращения к значению статусу кода. А в message содержится подробная причина ошибки, которая не всегда соответствует прямому описанию HTTP кода. Например, сообщения в случае, если в запросе вообще не указан ключ API и в случае, когда указан не существующий ключ, будут разные, но код ответа один — 403.

3. Здесь дело в том, что для пользователей в будущем планируется метод удаления. А поскольку мы отказались от метода DELETE, то единственным вариантом остается это сделать через
url: /v1/users/create и /v1/users/delete
. Для звонков же операция удаления бессмысленна, поэтому можно ограничиться POST запросом на /v1/calls, который позволит совершить звонок.

4. Мы не планировали смешивать в одной выдаче активные и совершенные звонки. Поэтому у нас нет GET-метода для /v1/calls.
По поводу /v1/calls?status=complete и /v1/calls?status=active — да, можно было сделать так. Здесь решили так не делать, чтобы избежать путаницы. Дело в том, что для совершенных запросов можно указать фильтр по номеру телефона и/или количеству дней за которые запрашиваются данные. Для активных же звонков данные фильтры не используются. Поэтому, решили использовать разные URL.
прекрасная статья, большое спасибо!
Ну вообще мы не подразумевали особой смысловой нагрузки в картинке :) хотя реализация API сервиса та ещё задача :)
Очень интересно вы подметили эмоциональное выражение взгляда робота на картинке, никогда бы не задумался об этом.
Обязательно учтём это и попытаемся сместить приоритеты в разработке, z0rgoyok спасибо за ваш совет
А у нас для этого есть функция в API, которая позволит вам получать список текущих вызовов с их параметрами (в данном случае номер телефона клиента), а для реализации кнопки ответить предусмотрели функцию оригинации которая сначала наберёт вашего оператора, а потом (когда оператор возьмёт трубку) осуществит вызов клиента.

Это и многое другое вы увидите в следующих сериях сможете реализовать на нашем сервисе с использование API RingCloud :)

Так что если интересно, готовы обсудить возможность попробовать до релиза API ;)
Полностью с вами согласен, но «софтовые» решения в сравнении с «железными» имеют как свои плюсы, так и минусы, например в стабильности работы. Аппаратный SIP телефон не зависит от настроек системы, неадекватности антивируса или сетевого экрана, его раз настроил и он работает. C WebRTC так же возможны проблемы, например с обновлением браузера
Пока мы не работаем с WebRTC но в дальнейших планах это есть
Сейчас занимаемся данным функционалом. Можем только сказать что он обязательно появится в скором времени и для нескольких вендоров
Из плюсов «не облачного решения»:
не зависит от связи с интернетом
заисит, так как отвалится интернет, отвалится и ваш провайдер телефонии, а от внутренних звонков компании толк не велик, особенно когда теряются звонки потенциальных клиентов, а у нас они не потеряются
не зависит от работы датацентра в котором размещена облачная АТС
У нас тоже не зависит ;) мы дублируемся
Админится также через веб рожу
можете привести пример такого решения где управление проще чем у нас?
Ну тут у каждого своё мнение и о том чем облако лучше написано не мало статей на хабре, всё же постараюсь привести несколько доводов основываясь на вашем комментарии:

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

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Date of birth
Registered
Activity