[asterisk-dev] [asterisk-app-dev] How do third party module developersexposetheir resources via asterisk ARI?

[David M. Lee]

On Oct 17, 2013, at 1:23 PM, Paul Albrecht <palbrecht at glccom.com> wrote:

> 
> On Oct 17, 2013, at 11:01 AM, David M. Lee <dlee at digium.com> wrote:
> 
>> 
>> On Oct 17, 2013, at 9:29 AM, Paul Albrecht <palbrecht at glccom.com> wrote:
>> 
>>> Is the ARI extendible as are other asterisk user interfaces like the CLI and AMI. That's the question. If not, why not?
>> 
>> 
>> Sort of. It's designed to be modular and allow for extension, but it's not great for external module developers yet.
>> 
>> The current process is:
>> 
>> 1. Write a new API declaration (rest-api/api-docs/fizzbin.json)
>> 2. Add your declaration to the master list (rest-api/resources.json)
>> 3. Run 'make ari-stubs'
>> 
>> This will generate several files.
>> * res/res_ari_fizzbin.c - Boiler plate code for parsing HTTP request, validating responses, etc.
>> * res/ari/resource_fizzbin.h - Boiler plate header file
>> * res/ari/resource_fizzbin.c - Implementation stubs
>> 
>> It will also update res/ari/ari_model_validators.h and res/ari/ari_model_validators.c with validators for your data models.
>> 
>> The res/ari/resource_fizzbin.c is the only one you modify. This is where you would implement your RESTful API.
>> 
>> I have a short list (in my head) of the changes that would be necessary to enable external ARI modules.
>> 
>> * Allow make_ari_stubs.py to be run against a single API declaration
>>  * In this case, model generators should be embedded in the module, instead of being put in res_ari_model.c
>> * Embed the API declaration in the generated res/res_ari_fizzbin.c
>> * Serve /ari/api-docs out of the modules instead of from the filesystem
>> * Build /ari/api-docs/resource.json dynamically from what's loaded instead of from the filesystem
>> 
> 
> Thanks for the info. Maybe it should be in the wiki.

I've put my wish-list to enable external ARI modules on my (newly created) ARI future work page[1].

> That said, I would expect an interface to register/unregister resource. Also, changing a resource shouldn't require recompiling asterisk.

It doesn't require recompiling Asterisk; the C code is modular. But the code generator needs some love in order to make this work well. (Hence my short list for ARI future work).

As far as registering a resource with ARI, the main function is ast_ari_add_handler()[2]. That call, and the code to build the stasis_rest_handlers tree that gets passed into it, resides in the generated res/res_ari_{resource}.c file.

 [1]: https://wiki.asterisk.org/wiki/x/mQeUAQ
 [2]: http://doxygen.asterisk.org/trunk/d4/d59/ari_8h.html#d960fe775504c2df60bcb7f7f9beb5b2

-- 
David M. Lee
Digium, Inc. | Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at:  www.digium.com  & www.asterisk.org