当1999年第一次创建Asterisk的时候，当初的设计想法是针对独立的Private Branch eXchange （PBX），它可以通过static.conf 文件来实现控制。呼叫控制是通过extensions.conf文件来实现，我们称之为拨号规则。
拨号规则的脚本通知Asterisk来执行呼叫流程中的应用程序。这种模式工作了很久时间。当然，随着技术的不断演进，现在的功能比以前更加灵活，同时也支持了更多的功能模块。
这些拨号规则的很多应用是由C语言开发，它们可以直接和Asterisk进行通信交换。这些应用可以访问通道，媒体，桥和endpoints和其他的对象，通过这些对象来实现电话通信。
关于 AMI 和 AGI
Asterisk项目创建不久， 两个应用程序接口就已经支持了Asterisk：Asterisk Gateway Interface （AGI） 和 Asterisk Manager Interface （AMI）。这两种接口是为了实现不同的目的：- AGI 和Apache中的CGI类似。AGI 提供了Asterisk拨号规则和外部程序通信的接口，它可以用来操作拨号规则中的通道。一般情况下，这个接口是同步的，从AGI程序中发起的对通道进行操作，流程完成后才能返回结果。
- AMI 则提供了一种在拨号规则中控制通道的机制。不像AGI，AMI 是异步的，是一种事件驱动的接口。大部分情况下，AMI 不负责控制通道执行-它提供通道状态信息，也提供在什么地方发起通道执行。
两个接口都非常强大，提供了多种集成度可能性。使用AGI的话，可以开启远端拨号规则的执行，这样就可以允许开发人员使用不同的程序语言PHP，Python，Java和其他的语言来集成Asterisk。使用AMI的话，可以显示Asterisk状态，发起的呼叫和被控制的通道地址。如果同时使用两种接口的话，可以把Asterisk当成是一种引擎来开发其他的应用。
但是使用这两个接口来开发自定义的通信应用程序时，这两种接口仍然存在一些缺点：
- AGI 是同步的方式来工作的，当对通道进行处理时，它会阻塞线程服务的AGI。当开发人员创建一个新的通信程序时，用户经常会需要获得通道的响应（DTMF事件，通道状态，等等）；所以AGI操作就会变得非常困难，如果配合AMI来进行操作的话，对开发人员是一个非常大的挑战。
- 拨号规则可能是一个局限。无论是使用 AMI 或者 AGI，用户的基本操作会限定在通道执行中。如果需要更加强大的功能支持，很多基本的APIs接口功能都不能获得很好的支持，例如这些APIs： bridges，endpoints，device state，message waiting indications，和通道中的实际媒体流处理。如果想通过AMI 和AGI来控制它们的话会变得非常困难，通常需要引入非常复杂的拨号规则控制流程来达到这些目的。
最后，两种接口AMI和AGI都是Asterisk项目的早期接口，他们具有一定的生命周期。尽管这两种接口非常强大，但是今天使用的技术中已不在是非常主要的手段。一些技术概念，例如SOAP， XML/JSON-RPC和REST也使用的不是非常多。因此需要一种原生态的，能够快速适应新技术开发Asterisk的技术来支持最新的技术发展潮流。
在Asterisk 12之前，如果用户需要开发一套自定义的通信程序的话，用户需要：
- 使用C语言开发一个Asterisk模块，或者
- 自己使用AGI或者AMI写一个自定义的程序来实现，可能有时需要两种接口同时使用来实现一个功能或使用一些小技巧修改拨号规则来实现这个功能。
ARI: 支持通信应用开发的接口
Asterisk RESTful Interface （ARI） 的出现就是为了解决用户的这些担心的。AMI的优势在于对呼叫的控制，AGI 的优势是通过外部程序来执行拨号规则的应用程序，它们都不是为开发人员设计支持开发人员创建自己的通信应用程序。ARI是一种异步工作方式，可以支持开发人员通过访问Asterisk中的原始对象实体来开发自己的通信应用程序，ARI可以通过REST接口访问，例如channels，bridges，endpoints和 media等等原始数据。对象实体的控制则通过WebSocket来访问JSON 事件来实现。
- ARI 不是通知通道执行VoiceMail拨号规则的application或在拨号规则中转发一个通道到VoiceMail。
- ARI可以支持用户创建一个自己的VoiceMail 应用程序。
- ARI 基础
- ARI 由3个部分组成。它们是：
- 一个 RESTful 接口支持终端来控制Asterisk的资源。
- 一个WebSocket，它在JSON中传输Asterisk资源到终端。
Stasis 拨号规则的应用模块，它来处理从Asterisk通道到终端的控制。
通过以上3个部分的结合，开发人员就可以实现对Asterisk基础资源的控制，实现自定义通信应用的开发。
什么是REST?
Representational State Transfer （REST） 是一种软件架构，它具有以下几个方面的特点：
- 通信方式是通过client-server 模式进行的。
- 通信是stateless的方式。服务器端不保存请求中的客户端状态。
- 连接分层，支持中间层实现路由和均衡负载。
- 非正式接口。请求中的资源和消息可以自己定义描述。
ARI 没有严格限定在一个REST API。Asterisk作为一个独立的应用，它同样建议状态信息，可以通过ARI修改。例如，SIP电话可能挂机，Asterisk就会对通道执行挂机命令，尽管终端通过ARI没有通知Asterisk对此SIP话机挂机。Asterisk以异步，state-ful 的工作方式工作：因此，ARI是RESTful。
什么是WebSocket?
WebSockets 是一种相对比较新的协议标准（RFC 6455），它可以支持客户端和服务器端的双向通信。此协议标准的主要目的是对基于浏览器的应用提供一种支持双向通信机制，不依赖于HTTP长时间的服务器查询或者其他非标准的机制。连接是用来传递从Asterisk到客户端的异步事件。这些事件是和RESTful 接口相关，但是它在技术上是独立的。Asterisk可以通知客户端本身的状态修改，在原来状态下，因为客户端混合使用了ARI。
什么是Stasis?
Stasis 是Asterisk拨号规则中的一个应用模块。它的机制是Asterisk 使用这个应用模块在拨号规则中实现通道控制。通常来说，ARI 应用程序在Stasis 拨号规则中控制通道和Asterisk的其他资源。不在Stasis 拨号规则中的通道不能被ARI来控制，总体来说，ARI的目的是用户创建自己的拨号规则应用程序，不是来控制当前存在的程序。
进一步了解
这里多个页面文档介绍ARI和一些举例。正常情况下，我们假设：
- 用户已经注册了一些SIP电话终端，可能使用chan_pjsip 或者 chan_sip。
- 用户已经对Asterisk有一定的基本了解。
- 对Python，JavaScript或者其他的高级开发语言有一定的了解。
大部分的经历不是直接创建HTTP REST 的结构，目前已经有很多开发包封装了这些接口。
获得有价值的技术分享：请访问www.freesip.org 技术论坛，关注公众号：asterisk-cn
