On Oct 17, 2013, at 1:23 PM, Paul Albrecht <palbrecht at glccom.com> wrote: >> 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 also create a "How to build an ARI resource" page - https://wiki.asterisk.org/wiki/x/ngeUAQ Feedback welcome. -- 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
