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 сервиса та ещё задача :)
Очень интересно вы подметили эмоциональное выражение взгляда робота на картинке, никогда бы не задумался об этом.
А у нас для этого есть функция в API, которая позволит вам получать список текущих вызовов с их параметрами (в данном случае номер телефона клиента), а для реализации кнопки ответить предусмотрели функцию оригинации которая сначала наберёт вашего оператора, а потом (когда оператор возьмёт трубку) осуществит вызов клиента.
Это и многое другое вы увидите в следующих сериях сможете реализовать на нашем сервисе с использование API RingCloud :)
Так что если интересно, готовы обсудить возможность попробовать до релиза API ;)
Полностью с вами согласен, но «софтовые» решения в сравнении с «железными» имеют как свои плюсы, так и минусы, например в стабильности работы. Аппаратный SIP телефон не зависит от настроек системы, неадекватности антивируса или сетевого экрана, его раз настроил и он работает. C WebRTC так же возможны проблемы, например с обновлением браузера
заисит, так как отвалится интернет, отвалится и ваш провайдер телефонии, а от внутренних звонков компании толк не велик, особенно когда теряются звонки потенциальных клиентов, а у нас они не потеряются
не зависит от работы датацентра в котором размещена облачная АТС
У нас тоже не зависит ;) мы дублируемся
Админится также через веб рожу
можете привести пример такого решения где управление проще чем у нас?
Ну тут у каждого своё мнение и о том чем облако лучше написано не мало статей на хабре, всё же постараюсь привести несколько доводов основываясь на вашем комментарии:
как минимум телефоны настраивать придется
— у нас для этого существует тех. поддержка которая поможет настроить и обучить пользователя
А если нужно больше сотрудников чем предусмотрено тарифными планами, позвоните нам, мы предложим вам индивидуальный тариф с требуемым количеством пользователей.
Или попадется клиент, который кроме 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, то единственным вариантом остается это сделать через . Для звонков же операция удаления бессмысленна, поэтому можно ограничиться POST запросом на /v1/calls, который позволит совершить звонок.
4. Мы не планировали смешивать в одной выдаче активные и совершенные звонки. Поэтому у нас нет GET-метода для /v1/calls.
По поводу /v1/calls?status=complete и /v1/calls?status=active — да, можно было сделать так. Здесь решили так не делать, чтобы избежать путаницы. Дело в том, что для совершенных запросов можно указать фильтр по номеру телефона и/или количеству дней за которые запрашиваются данные. Для активных же звонков данные фильтры не используются. Поэтому, решили использовать разные URL.
Очень интересно вы подметили эмоциональное выражение взгляда робота на картинке, никогда бы не задумался об этом.
Это и многое другое вы
увидите в следующих серияхсможете реализовать на нашем сервисе с использование API RingCloud :)Так что если интересно, готовы обсудить возможность попробовать до релиза API ;)
заисит, так как отвалится интернет, отвалится и ваш провайдер телефонии, а от внутренних звонков компании толк не велик, особенно когда теряются звонки потенциальных клиентов, а у нас они не потеряются
У нас тоже не зависит ;) мы дублируемся
можете привести пример такого решения где управление проще чем у нас?
— у нас для этого существует тех. поддержка которая поможет настроить и обучить пользователя