[asterisk-app-dev] How do third party module developersexposetheir resources via asterisk ARI?
David M. Lee
dlee at digium.com
Thu Oct 17 13:58:59 CDT 2013
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
More information about the asterisk-app-dev
mailing list