2013-04-22 14:58:53 +00:00
/*
* Asterisk - - An open source telephony toolkit .
*
* Copyright ( C ) 2012 - 2013 , Digium , Inc .
*
* David M . Lee , II < dlee @ digium . com >
*
* See http : //www.asterisk.org for more information about
* the Asterisk project . Please do not directly contact
* any of the maintainers of this project for assistance ;
* the project provides a web site , mailing lists and IRC
* channels for your use .
*
* This program is free software , distributed under the terms of
* the GNU General Public License Version 2. See the LICENSE file
* at the top of the source tree .
*/
/*
* ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! !
* ! ! ! ! ! DO NOT EDIT ! ! ! ! !
* ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! !
* This file is generated by a mustache template . Please see the original
2013-07-27 23:11:02 +00:00
* template in rest - api - templates / res_ari_resource . c . mustache
2013-04-22 14:58:53 +00:00
*/
/*! \file
*
* \ brief Bridge resources
*
* \ author David M . Lee , II < dlee @ digium . com >
*/
/*** MODULEINFO
2013-07-27 23:11:02 +00:00
< depend type = " module " > res_ari < / depend >
2015-04-29 07:46:44 -04:00
< depend type = " module " > res_ari_model < / depend >
2013-05-10 17:12:57 +00:00
< depend type = " module " > res_stasis < / depend >
2018-01-18 10:01:26 -05:00
< depend type = " module " > res_stasis_recording < / depend >
< depend type = " module " > res_stasis_playback < / depend >
2013-04-22 14:58:53 +00:00
< support_level > core < / support_level >
* * */
# include "asterisk.h"
2013-08-02 14:36:32 +00:00
# include "asterisk/app.h"
2013-04-22 14:58:53 +00:00
# include "asterisk/module.h"
2013-05-10 17:12:57 +00:00
# include "asterisk/stasis_app.h"
2013-07-27 23:11:02 +00:00
# include "ari/resource_bridges.h"
Update events to use Swagger 1.3 subtyping, and related aftermath
This patch started with the simple idea of changing the /events data
model to be more sane. The original model would send out events like:
{ "stasis_start": { "args": [], "channel": { ... } } }
The event discriminator was the field name instead of being a value in
the object, due to limitations in how Swagger 1.1 could model objects.
While technically sufficient in communicating event information, it was
really difficult to deal with in terms of client side JSON handling.
This patch takes advantage of a proposed extension[1] to Swagger which
allows type variance through the use of a discriminator field. This had
a domino effect that made this a surprisingly large patch.
[1]: https://groups.google.com/d/msg/wordnik-api/EC3rGajE0os/ey_5dBI_jWcJ
In changing the models, I also had to change the swagger_model.py
processor so it can handle the type discriminator and subtyping. I took
that a big step forward, and using that information to generate an
ari_model module, which can validate a JSON object against the Swagger
model.
The REST and WebSocket generators were changed to take advantage of the
validators. If compiled with AST_DEVMODE enabled, JSON objects that
don't match their corresponding models will not be sent out. For REST
API calls, a 500 Internal Server response is sent. For WebSockets, the
invalid JSON message is replaced with an error message.
Since this took over about half of the job of the existing JSON
generators, and the .to_json virtual function on messages took over the
other half, I reluctantly removed the generators.
The validators turned up all sorts of errors and inconsistencies in our
data models, and the code. These were cleaned up, with checks in the
code generator avoid some of the consistency problems in the future.
* The model for a channel snapshot was trimmed down to match the
information sent via AMI. Many of the field being sent were not
useful in the general case.
* The model for a bridge snapshot was updated to be more consistent
with the other ARI models.
Another impact of introducing subtyping was that the swagger-codegen
documentation generator was insufficient (at least until it catches up
with Swagger 1.2). I wanted it to be easier to generate docs for the API
anyways, so I ported the wiki pages to use the Asterisk Swagger
generator. In the process, I was able to clean up many of the model
links, which would occasionally give inconsistent results on the wiki. I
also added error responses to the wiki docs, making the wiki
documentation more complete.
Finally, since Stasis-HTTP will now be named Asterisk REST Interface
(ARI), any new functions and files I created carry the ari_ prefix. I
changed a few stasis_http references to ari where it was non-intrusive
and made sense.
(closes issue ASTERISK-21885)
Review: https://reviewboard.asterisk.org/r/2639/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393529 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-07-03 16:32:41 +00:00
# if defined(AST_DEVMODE)
2013-07-27 23:11:02 +00:00
# include "ari/ari_model_validators.h"
Update events to use Swagger 1.3 subtyping, and related aftermath
This patch started with the simple idea of changing the /events data
model to be more sane. The original model would send out events like:
{ "stasis_start": { "args": [], "channel": { ... } } }
The event discriminator was the field name instead of being a value in
the object, due to limitations in how Swagger 1.1 could model objects.
While technically sufficient in communicating event information, it was
really difficult to deal with in terms of client side JSON handling.
This patch takes advantage of a proposed extension[1] to Swagger which
allows type variance through the use of a discriminator field. This had
a domino effect that made this a surprisingly large patch.
[1]: https://groups.google.com/d/msg/wordnik-api/EC3rGajE0os/ey_5dBI_jWcJ
In changing the models, I also had to change the swagger_model.py
processor so it can handle the type discriminator and subtyping. I took
that a big step forward, and using that information to generate an
ari_model module, which can validate a JSON object against the Swagger
model.
The REST and WebSocket generators were changed to take advantage of the
validators. If compiled with AST_DEVMODE enabled, JSON objects that
don't match their corresponding models will not be sent out. For REST
API calls, a 500 Internal Server response is sent. For WebSockets, the
invalid JSON message is replaced with an error message.
Since this took over about half of the job of the existing JSON
generators, and the .to_json virtual function on messages took over the
other half, I reluctantly removed the generators.
The validators turned up all sorts of errors and inconsistencies in our
data models, and the code. These were cleaned up, with checks in the
code generator avoid some of the consistency problems in the future.
* The model for a channel snapshot was trimmed down to match the
information sent via AMI. Many of the field being sent were not
useful in the general case.
* The model for a bridge snapshot was updated to be more consistent
with the other ARI models.
Another impact of introducing subtyping was that the swagger-codegen
documentation generator was insufficient (at least until it catches up
with Swagger 1.2). I wanted it to be easier to generate docs for the API
anyways, so I ported the wiki pages to use the Asterisk Swagger
generator. In the process, I was able to clean up many of the model
links, which would occasionally give inconsistent results on the wiki. I
also added error responses to the wiki docs, making the wiki
documentation more complete.
Finally, since Stasis-HTTP will now be named Asterisk REST Interface
(ARI), any new functions and files I created carry the ari_ prefix. I
changed a few stasis_http references to ari where it was non-intrusive
and made sense.
(closes issue ASTERISK-21885)
Review: https://reviewboard.asterisk.org/r/2639/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393529 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-07-03 16:32:41 +00:00
# endif
2013-04-22 14:58:53 +00:00
2013-08-02 14:36:32 +00:00
# define MAX_VALS 128
2013-04-22 14:58:53 +00:00
/*!
* \ brief Parameter parsing callback for / bridges .
2021-11-17 13:18:32 +01:00
* \ param ser TCP / TLS session object
2013-04-22 14:58:53 +00:00
* \ param get_params GET parameters in the HTTP request .
* \ param path_vars Path variables extracted from the request .
* \ param headers HTTP headers .
2021-11-17 13:18:32 +01:00
* \ param body
2013-04-22 14:58:53 +00:00
* \ param [ out ] response Response to the HTTP request .
*/
2013-11-07 21:10:31 +00:00
static void ast_ari_bridges_list_cb (
2013-11-27 15:48:39 +00:00
struct ast_tcptls_session_instance * ser ,
Update events to use Swagger 1.3 subtyping, and related aftermath
This patch started with the simple idea of changing the /events data
model to be more sane. The original model would send out events like:
{ "stasis_start": { "args": [], "channel": { ... } } }
The event discriminator was the field name instead of being a value in
the object, due to limitations in how Swagger 1.1 could model objects.
While technically sufficient in communicating event information, it was
really difficult to deal with in terms of client side JSON handling.
This patch takes advantage of a proposed extension[1] to Swagger which
allows type variance through the use of a discriminator field. This had
a domino effect that made this a surprisingly large patch.
[1]: https://groups.google.com/d/msg/wordnik-api/EC3rGajE0os/ey_5dBI_jWcJ
In changing the models, I also had to change the swagger_model.py
processor so it can handle the type discriminator and subtyping. I took
that a big step forward, and using that information to generate an
ari_model module, which can validate a JSON object against the Swagger
model.
The REST and WebSocket generators were changed to take advantage of the
validators. If compiled with AST_DEVMODE enabled, JSON objects that
don't match their corresponding models will not be sent out. For REST
API calls, a 500 Internal Server response is sent. For WebSockets, the
invalid JSON message is replaced with an error message.
Since this took over about half of the job of the existing JSON
generators, and the .to_json virtual function on messages took over the
other half, I reluctantly removed the generators.
The validators turned up all sorts of errors and inconsistencies in our
data models, and the code. These were cleaned up, with checks in the
code generator avoid some of the consistency problems in the future.
* The model for a channel snapshot was trimmed down to match the
information sent via AMI. Many of the field being sent were not
useful in the general case.
* The model for a bridge snapshot was updated to be more consistent
with the other ARI models.
Another impact of introducing subtyping was that the swagger-codegen
documentation generator was insufficient (at least until it catches up
with Swagger 1.2). I wanted it to be easier to generate docs for the API
anyways, so I ported the wiki pages to use the Asterisk Swagger
generator. In the process, I was able to clean up many of the model
links, which would occasionally give inconsistent results on the wiki. I
also added error responses to the wiki docs, making the wiki
documentation more complete.
Finally, since Stasis-HTTP will now be named Asterisk REST Interface
(ARI), any new functions and files I created carry the ari_ prefix. I
changed a few stasis_http references to ari where it was non-intrusive
and made sense.
(closes issue ASTERISK-21885)
Review: https://reviewboard.asterisk.org/r/2639/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393529 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-07-03 16:32:41 +00:00
struct ast_variable * get_params , struct ast_variable * path_vars ,
2017-01-19 08:05:36 -07:00
struct ast_variable * headers , struct ast_json * body , struct ast_ari_response * response )
2013-04-22 14:58:53 +00:00
{
2013-11-07 21:10:31 +00:00
struct ast_ari_bridges_list_args args = { } ;
Update events to use Swagger 1.3 subtyping, and related aftermath
This patch started with the simple idea of changing the /events data
model to be more sane. The original model would send out events like:
{ "stasis_start": { "args": [], "channel": { ... } } }
The event discriminator was the field name instead of being a value in
the object, due to limitations in how Swagger 1.1 could model objects.
While technically sufficient in communicating event information, it was
really difficult to deal with in terms of client side JSON handling.
This patch takes advantage of a proposed extension[1] to Swagger which
allows type variance through the use of a discriminator field. This had
a domino effect that made this a surprisingly large patch.
[1]: https://groups.google.com/d/msg/wordnik-api/EC3rGajE0os/ey_5dBI_jWcJ
In changing the models, I also had to change the swagger_model.py
processor so it can handle the type discriminator and subtyping. I took
that a big step forward, and using that information to generate an
ari_model module, which can validate a JSON object against the Swagger
model.
The REST and WebSocket generators were changed to take advantage of the
validators. If compiled with AST_DEVMODE enabled, JSON objects that
don't match their corresponding models will not be sent out. For REST
API calls, a 500 Internal Server response is sent. For WebSockets, the
invalid JSON message is replaced with an error message.
Since this took over about half of the job of the existing JSON
generators, and the .to_json virtual function on messages took over the
other half, I reluctantly removed the generators.
The validators turned up all sorts of errors and inconsistencies in our
data models, and the code. These were cleaned up, with checks in the
code generator avoid some of the consistency problems in the future.
* The model for a channel snapshot was trimmed down to match the
information sent via AMI. Many of the field being sent were not
useful in the general case.
* The model for a bridge snapshot was updated to be more consistent
with the other ARI models.
Another impact of introducing subtyping was that the swagger-codegen
documentation generator was insufficient (at least until it catches up
with Swagger 1.2). I wanted it to be easier to generate docs for the API
anyways, so I ported the wiki pages to use the Asterisk Swagger
generator. In the process, I was able to clean up many of the model
links, which would occasionally give inconsistent results on the wiki. I
also added error responses to the wiki docs, making the wiki
documentation more complete.
Finally, since Stasis-HTTP will now be named Asterisk REST Interface
(ARI), any new functions and files I created carry the ari_ prefix. I
changed a few stasis_http references to ari where it was non-intrusive
and made sense.
(closes issue ASTERISK-21885)
Review: https://reviewboard.asterisk.org/r/2639/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393529 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-07-03 16:32:41 +00:00
# if defined(AST_DEVMODE)
int is_valid ;
int code ;
# endif /* AST_DEVMODE */
2013-11-07 21:10:31 +00:00
ast_ari_bridges_list ( headers , & args , response ) ;
Update events to use Swagger 1.3 subtyping, and related aftermath
This patch started with the simple idea of changing the /events data
model to be more sane. The original model would send out events like:
{ "stasis_start": { "args": [], "channel": { ... } } }
The event discriminator was the field name instead of being a value in
the object, due to limitations in how Swagger 1.1 could model objects.
While technically sufficient in communicating event information, it was
really difficult to deal with in terms of client side JSON handling.
This patch takes advantage of a proposed extension[1] to Swagger which
allows type variance through the use of a discriminator field. This had
a domino effect that made this a surprisingly large patch.
[1]: https://groups.google.com/d/msg/wordnik-api/EC3rGajE0os/ey_5dBI_jWcJ
In changing the models, I also had to change the swagger_model.py
processor so it can handle the type discriminator and subtyping. I took
that a big step forward, and using that information to generate an
ari_model module, which can validate a JSON object against the Swagger
model.
The REST and WebSocket generators were changed to take advantage of the
validators. If compiled with AST_DEVMODE enabled, JSON objects that
don't match their corresponding models will not be sent out. For REST
API calls, a 500 Internal Server response is sent. For WebSockets, the
invalid JSON message is replaced with an error message.
Since this took over about half of the job of the existing JSON
generators, and the .to_json virtual function on messages took over the
other half, I reluctantly removed the generators.
The validators turned up all sorts of errors and inconsistencies in our
data models, and the code. These were cleaned up, with checks in the
code generator avoid some of the consistency problems in the future.
* The model for a channel snapshot was trimmed down to match the
information sent via AMI. Many of the field being sent were not
useful in the general case.
* The model for a bridge snapshot was updated to be more consistent
with the other ARI models.
Another impact of introducing subtyping was that the swagger-codegen
documentation generator was insufficient (at least until it catches up
with Swagger 1.2). I wanted it to be easier to generate docs for the API
anyways, so I ported the wiki pages to use the Asterisk Swagger
generator. In the process, I was able to clean up many of the model
links, which would occasionally give inconsistent results on the wiki. I
also added error responses to the wiki docs, making the wiki
documentation more complete.
Finally, since Stasis-HTTP will now be named Asterisk REST Interface
(ARI), any new functions and files I created carry the ari_ prefix. I
changed a few stasis_http references to ari where it was non-intrusive
and made sense.
(closes issue ASTERISK-21885)
Review: https://reviewboard.asterisk.org/r/2639/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393529 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-07-03 16:32:41 +00:00
# if defined(AST_DEVMODE)
code = response - > response_code ;
switch ( code ) {
2013-07-23 14:57:03 +00:00
case 0 : /* Implementation is still a stub, or the code wasn't set */
is_valid = response - > message = = NULL ;
break ;
case 500 : /* Internal Server Error */
case 501 : /* Not Implemented */
Update events to use Swagger 1.3 subtyping, and related aftermath
This patch started with the simple idea of changing the /events data
model to be more sane. The original model would send out events like:
{ "stasis_start": { "args": [], "channel": { ... } } }
The event discriminator was the field name instead of being a value in
the object, due to limitations in how Swagger 1.1 could model objects.
While technically sufficient in communicating event information, it was
really difficult to deal with in terms of client side JSON handling.
This patch takes advantage of a proposed extension[1] to Swagger which
allows type variance through the use of a discriminator field. This had
a domino effect that made this a surprisingly large patch.
[1]: https://groups.google.com/d/msg/wordnik-api/EC3rGajE0os/ey_5dBI_jWcJ
In changing the models, I also had to change the swagger_model.py
processor so it can handle the type discriminator and subtyping. I took
that a big step forward, and using that information to generate an
ari_model module, which can validate a JSON object against the Swagger
model.
The REST and WebSocket generators were changed to take advantage of the
validators. If compiled with AST_DEVMODE enabled, JSON objects that
don't match their corresponding models will not be sent out. For REST
API calls, a 500 Internal Server response is sent. For WebSockets, the
invalid JSON message is replaced with an error message.
Since this took over about half of the job of the existing JSON
generators, and the .to_json virtual function on messages took over the
other half, I reluctantly removed the generators.
The validators turned up all sorts of errors and inconsistencies in our
data models, and the code. These were cleaned up, with checks in the
code generator avoid some of the consistency problems in the future.
* The model for a channel snapshot was trimmed down to match the
information sent via AMI. Many of the field being sent were not
useful in the general case.
* The model for a bridge snapshot was updated to be more consistent
with the other ARI models.
Another impact of introducing subtyping was that the swagger-codegen
documentation generator was insufficient (at least until it catches up
with Swagger 1.2). I wanted it to be easier to generate docs for the API
anyways, so I ported the wiki pages to use the Asterisk Swagger
generator. In the process, I was able to clean up many of the model
links, which would occasionally give inconsistent results on the wiki. I
also added error responses to the wiki docs, making the wiki
documentation more complete.
Finally, since Stasis-HTTP will now be named Asterisk REST Interface
(ARI), any new functions and files I created carry the ari_ prefix. I
changed a few stasis_http references to ari where it was non-intrusive
and made sense.
(closes issue ASTERISK-21885)
Review: https://reviewboard.asterisk.org/r/2639/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393529 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-07-03 16:32:41 +00:00
is_valid = 1 ;
break ;
default :
if ( 200 < = code & & code < = 299 ) {
2013-07-27 23:11:02 +00:00
is_valid = ast_ari_validate_list ( response - > message ,
ast_ari_validate_bridge_fn ( ) ) ;
Update events to use Swagger 1.3 subtyping, and related aftermath
This patch started with the simple idea of changing the /events data
model to be more sane. The original model would send out events like:
{ "stasis_start": { "args": [], "channel": { ... } } }
The event discriminator was the field name instead of being a value in
the object, due to limitations in how Swagger 1.1 could model objects.
While technically sufficient in communicating event information, it was
really difficult to deal with in terms of client side JSON handling.
This patch takes advantage of a proposed extension[1] to Swagger which
allows type variance through the use of a discriminator field. This had
a domino effect that made this a surprisingly large patch.
[1]: https://groups.google.com/d/msg/wordnik-api/EC3rGajE0os/ey_5dBI_jWcJ
In changing the models, I also had to change the swagger_model.py
processor so it can handle the type discriminator and subtyping. I took
that a big step forward, and using that information to generate an
ari_model module, which can validate a JSON object against the Swagger
model.
The REST and WebSocket generators were changed to take advantage of the
validators. If compiled with AST_DEVMODE enabled, JSON objects that
don't match their corresponding models will not be sent out. For REST
API calls, a 500 Internal Server response is sent. For WebSockets, the
invalid JSON message is replaced with an error message.
Since this took over about half of the job of the existing JSON
generators, and the .to_json virtual function on messages took over the
other half, I reluctantly removed the generators.
The validators turned up all sorts of errors and inconsistencies in our
data models, and the code. These were cleaned up, with checks in the
code generator avoid some of the consistency problems in the future.
* The model for a channel snapshot was trimmed down to match the
information sent via AMI. Many of the field being sent were not
useful in the general case.
* The model for a bridge snapshot was updated to be more consistent
with the other ARI models.
Another impact of introducing subtyping was that the swagger-codegen
documentation generator was insufficient (at least until it catches up
with Swagger 1.2). I wanted it to be easier to generate docs for the API
anyways, so I ported the wiki pages to use the Asterisk Swagger
generator. In the process, I was able to clean up many of the model
links, which would occasionally give inconsistent results on the wiki. I
also added error responses to the wiki docs, making the wiki
documentation more complete.
Finally, since Stasis-HTTP will now be named Asterisk REST Interface
(ARI), any new functions and files I created carry the ari_ prefix. I
changed a few stasis_http references to ari where it was non-intrusive
and made sense.
(closes issue ASTERISK-21885)
Review: https://reviewboard.asterisk.org/r/2639/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393529 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-07-03 16:32:41 +00:00
} else {
ast_log ( LOG_ERROR , " Invalid error response %d for /bridges \n " , code ) ;
is_valid = 0 ;
}
}
if ( ! is_valid ) {
ast_log ( LOG_ERROR , " Response validation failed for /bridges \n " ) ;
2013-07-27 23:11:02 +00:00
ast_ari_response_error ( response , 500 ,
Update events to use Swagger 1.3 subtyping, and related aftermath
This patch started with the simple idea of changing the /events data
model to be more sane. The original model would send out events like:
{ "stasis_start": { "args": [], "channel": { ... } } }
The event discriminator was the field name instead of being a value in
the object, due to limitations in how Swagger 1.1 could model objects.
While technically sufficient in communicating event information, it was
really difficult to deal with in terms of client side JSON handling.
This patch takes advantage of a proposed extension[1] to Swagger which
allows type variance through the use of a discriminator field. This had
a domino effect that made this a surprisingly large patch.
[1]: https://groups.google.com/d/msg/wordnik-api/EC3rGajE0os/ey_5dBI_jWcJ
In changing the models, I also had to change the swagger_model.py
processor so it can handle the type discriminator and subtyping. I took
that a big step forward, and using that information to generate an
ari_model module, which can validate a JSON object against the Swagger
model.
The REST and WebSocket generators were changed to take advantage of the
validators. If compiled with AST_DEVMODE enabled, JSON objects that
don't match their corresponding models will not be sent out. For REST
API calls, a 500 Internal Server response is sent. For WebSockets, the
invalid JSON message is replaced with an error message.
Since this took over about half of the job of the existing JSON
generators, and the .to_json virtual function on messages took over the
other half, I reluctantly removed the generators.
The validators turned up all sorts of errors and inconsistencies in our
data models, and the code. These were cleaned up, with checks in the
code generator avoid some of the consistency problems in the future.
* The model for a channel snapshot was trimmed down to match the
information sent via AMI. Many of the field being sent were not
useful in the general case.
* The model for a bridge snapshot was updated to be more consistent
with the other ARI models.
Another impact of introducing subtyping was that the swagger-codegen
documentation generator was insufficient (at least until it catches up
with Swagger 1.2). I wanted it to be easier to generate docs for the API
anyways, so I ported the wiki pages to use the Asterisk Swagger
generator. In the process, I was able to clean up many of the model
links, which would occasionally give inconsistent results on the wiki. I
also added error responses to the wiki docs, making the wiki
documentation more complete.
Finally, since Stasis-HTTP will now be named Asterisk REST Interface
(ARI), any new functions and files I created carry the ari_ prefix. I
changed a few stasis_http references to ari where it was non-intrusive
and made sense.
(closes issue ASTERISK-21885)
Review: https://reviewboard.asterisk.org/r/2639/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393529 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-07-03 16:32:41 +00:00
" Internal Server Error " , " Response validation failed " ) ;
}
# endif /* AST_DEVMODE */
2013-08-02 14:36:32 +00:00
fin : __attribute__ ( ( unused ) )
return ;
2013-04-22 14:58:53 +00:00
}
2014-01-21 14:27:21 +00:00
int ast_ari_bridges_create_parse_body (
struct ast_json * body ,
struct ast_ari_bridges_create_args * args )
{
struct ast_json * field ;
/* Parse query parameters out of it */
field = ast_json_object_get ( body , " type " ) ;
if ( field ) {
args - > type = ast_json_string_get ( field ) ;
}
uniqueid: channel linkedid, ami, ari object creation with id's
Much needed was a way to assign id to objects on creation, and
much change was necessary to accomplish it. Channel uniqueids
and linkedids are split into separate string and creation time
components without breaking linkedid propgation. This allowed
the uniqueid to be specified by the user interface - and those
values are now carried through to channel creation, adding the
assignedids value to every function in the chain including the
channel drivers. For local channels, the second channel can be
specified or left to default to a ;2 suffix of first. In ARI,
bridge, playback, and snoop objects can also be created with a
specified uniqueid.
Along the way, the args order to allocating channels was fixed
in chan_mgcp and chan_gtalk, and linkedid is no longer lost as
masquerade occurs.
(closes issue ASTERISK-23120)
Review: https://reviewboard.asterisk.org/r/3191/
........
Merged revisions 410157 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410158 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-03-07 15:47:55 +00:00
field = ast_json_object_get ( body , " bridgeId " ) ;
if ( field ) {
args - > bridge_id = ast_json_string_get ( field ) ;
}
2014-01-21 14:27:21 +00:00
field = ast_json_object_get ( body , " name " ) ;
if ( field ) {
args - > name = ast_json_string_get ( field ) ;
}
return 0 ;
}
2013-04-22 14:58:53 +00:00
/*!
* \ brief Parameter parsing callback for / bridges .
2021-11-17 13:18:32 +01:00
* \ param ser TCP / TLS session object
2013-04-22 14:58:53 +00:00
* \ param get_params GET parameters in the HTTP request .
* \ param path_vars Path variables extracted from the request .
* \ param headers HTTP headers .
2021-11-17 13:18:32 +01:00
* \ param body
2013-04-22 14:58:53 +00:00
* \ param [ out ] response Response to the HTTP request .
*/
2013-11-07 21:10:31 +00:00
static void ast_ari_bridges_create_cb (
2013-11-27 15:48:39 +00:00
struct ast_tcptls_session_instance * ser ,
Update events to use Swagger 1.3 subtyping, and related aftermath
This patch started with the simple idea of changing the /events data
model to be more sane. The original model would send out events like:
{ "stasis_start": { "args": [], "channel": { ... } } }
The event discriminator was the field name instead of being a value in
the object, due to limitations in how Swagger 1.1 could model objects.
While technically sufficient in communicating event information, it was
really difficult to deal with in terms of client side JSON handling.
This patch takes advantage of a proposed extension[1] to Swagger which
allows type variance through the use of a discriminator field. This had
a domino effect that made this a surprisingly large patch.
[1]: https://groups.google.com/d/msg/wordnik-api/EC3rGajE0os/ey_5dBI_jWcJ
In changing the models, I also had to change the swagger_model.py
processor so it can handle the type discriminator and subtyping. I took
that a big step forward, and using that information to generate an
ari_model module, which can validate a JSON object against the Swagger
model.
The REST and WebSocket generators were changed to take advantage of the
validators. If compiled with AST_DEVMODE enabled, JSON objects that
don't match their corresponding models will not be sent out. For REST
API calls, a 500 Internal Server response is sent. For WebSockets, the
invalid JSON message is replaced with an error message.
Since this took over about half of the job of the existing JSON
generators, and the .to_json virtual function on messages took over the
other half, I reluctantly removed the generators.
The validators turned up all sorts of errors and inconsistencies in our
data models, and the code. These were cleaned up, with checks in the
code generator avoid some of the consistency problems in the future.
* The model for a channel snapshot was trimmed down to match the
information sent via AMI. Many of the field being sent were not
useful in the general case.
* The model for a bridge snapshot was updated to be more consistent
with the other ARI models.
Another impact of introducing subtyping was that the swagger-codegen
documentation generator was insufficient (at least until it catches up
with Swagger 1.2). I wanted it to be easier to generate docs for the API
anyways, so I ported the wiki pages to use the Asterisk Swagger
generator. In the process, I was able to clean up many of the model
links, which would occasionally give inconsistent results on the wiki. I
also added error responses to the wiki docs, making the wiki
documentation more complete.
Finally, since Stasis-HTTP will now be named Asterisk REST Interface
(ARI), any new functions and files I created carry the ari_ prefix. I
changed a few stasis_http references to ari where it was non-intrusive
and made sense.
(closes issue ASTERISK-21885)
Review: https://reviewboard.asterisk.org/r/2639/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393529 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-07-03 16:32:41 +00:00
struct ast_variable * get_params , struct ast_variable * path_vars ,
2017-01-19 08:05:36 -07:00
struct ast_variable * headers , struct ast_json * body , struct ast_ari_response * response )
2013-04-22 14:58:53 +00:00
{
2013-11-07 21:10:31 +00:00
struct ast_ari_bridges_create_args args = { } ;
2013-08-02 14:36:32 +00:00
struct ast_variable * i ;
Update events to use Swagger 1.3 subtyping, and related aftermath
This patch started with the simple idea of changing the /events data
model to be more sane. The original model would send out events like:
{ "stasis_start": { "args": [], "channel": { ... } } }
The event discriminator was the field name instead of being a value in
the object, due to limitations in how Swagger 1.1 could model objects.
While technically sufficient in communicating event information, it was
really difficult to deal with in terms of client side JSON handling.
This patch takes advantage of a proposed extension[1] to Swagger which
allows type variance through the use of a discriminator field. This had
a domino effect that made this a surprisingly large patch.
[1]: https://groups.google.com/d/msg/wordnik-api/EC3rGajE0os/ey_5dBI_jWcJ
In changing the models, I also had to change the swagger_model.py
processor so it can handle the type discriminator and subtyping. I took
that a big step forward, and using that information to generate an
ari_model module, which can validate a JSON object against the Swagger
model.
The REST and WebSocket generators were changed to take advantage of the
validators. If compiled with AST_DEVMODE enabled, JSON objects that
don't match their corresponding models will not be sent out. For REST
API calls, a 500 Internal Server response is sent. For WebSockets, the
invalid JSON message is replaced with an error message.
Since this took over about half of the job of the existing JSON
generators, and the .to_json virtual function on messages took over the
other half, I reluctantly removed the generators.
The validators turned up all sorts of errors and inconsistencies in our
data models, and the code. These were cleaned up, with checks in the
code generator avoid some of the consistency problems in the future.
* The model for a channel snapshot was trimmed down to match the
information sent via AMI. Many of the field being sent were not
useful in the general case.
* The model for a bridge snapshot was updated to be more consistent
with the other ARI models.
Another impact of introducing subtyping was that the swagger-codegen
documentation generator was insufficient (at least until it catches up
with Swagger 1.2). I wanted it to be easier to generate docs for the API
anyways, so I ported the wiki pages to use the Asterisk Swagger
generator. In the process, I was able to clean up many of the model
links, which would occasionally give inconsistent results on the wiki. I
also added error responses to the wiki docs, making the wiki
documentation more complete.
Finally, since Stasis-HTTP will now be named Asterisk REST Interface
(ARI), any new functions and files I created carry the ari_ prefix. I
changed a few stasis_http references to ari where it was non-intrusive
and made sense.
(closes issue ASTERISK-21885)
Review: https://reviewboard.asterisk.org/r/2639/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393529 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-07-03 16:32:41 +00:00
# if defined(AST_DEVMODE)
int is_valid ;
int code ;
# endif /* AST_DEVMODE */
2013-04-22 14:58:53 +00:00
for ( i = get_params ; i ; i = i - > next ) {
if ( strcmp ( i - > name , " type " ) = = 0 ) {
args . type = ( i - > value ) ;
} else
uniqueid: channel linkedid, ami, ari object creation with id's
Much needed was a way to assign id to objects on creation, and
much change was necessary to accomplish it. Channel uniqueids
and linkedids are split into separate string and creation time
components without breaking linkedid propgation. This allowed
the uniqueid to be specified by the user interface - and those
values are now carried through to channel creation, adding the
assignedids value to every function in the chain including the
channel drivers. For local channels, the second channel can be
specified or left to default to a ;2 suffix of first. In ARI,
bridge, playback, and snoop objects can also be created with a
specified uniqueid.
Along the way, the args order to allocating channels was fixed
in chan_mgcp and chan_gtalk, and linkedid is no longer lost as
masquerade occurs.
(closes issue ASTERISK-23120)
Review: https://reviewboard.asterisk.org/r/3191/
........
Merged revisions 410157 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410158 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-03-07 15:47:55 +00:00
if ( strcmp ( i - > name , " bridgeId " ) = = 0 ) {
args . bridge_id = ( i - > value ) ;
} else
2013-12-17 23:25:49 +00:00
if ( strcmp ( i - > name , " name " ) = = 0 ) {
args . name = ( i - > value ) ;
} else
2013-04-22 14:58:53 +00:00
{ }
}
2014-01-21 14:27:21 +00:00
if ( ast_ari_bridges_create_parse_body ( body , & args ) ) {
ast_ari_response_alloc_failed ( response ) ;
goto fin ;
2013-12-17 23:25:49 +00:00
}
2013-11-07 21:10:31 +00:00
ast_ari_bridges_create ( headers , & args , response ) ;
Update events to use Swagger 1.3 subtyping, and related aftermath
This patch started with the simple idea of changing the /events data
model to be more sane. The original model would send out events like:
{ "stasis_start": { "args": [], "channel": { ... } } }
The event discriminator was the field name instead of being a value in
the object, due to limitations in how Swagger 1.1 could model objects.
While technically sufficient in communicating event information, it was
really difficult to deal with in terms of client side JSON handling.
This patch takes advantage of a proposed extension[1] to Swagger which
allows type variance through the use of a discriminator field. This had
a domino effect that made this a surprisingly large patch.
[1]: https://groups.google.com/d/msg/wordnik-api/EC3rGajE0os/ey_5dBI_jWcJ
In changing the models, I also had to change the swagger_model.py
processor so it can handle the type discriminator and subtyping. I took
that a big step forward, and using that information to generate an
ari_model module, which can validate a JSON object against the Swagger
model.
The REST and WebSocket generators were changed to take advantage of the
validators. If compiled with AST_DEVMODE enabled, JSON objects that
don't match their corresponding models will not be sent out. For REST
API calls, a 500 Internal Server response is sent. For WebSockets, the
invalid JSON message is replaced with an error message.
Since this took over about half of the job of the existing JSON
generators, and the .to_json virtual function on messages took over the
other half, I reluctantly removed the generators.
The validators turned up all sorts of errors and inconsistencies in our
data models, and the code. These were cleaned up, with checks in the
code generator avoid some of the consistency problems in the future.
* The model for a channel snapshot was trimmed down to match the
information sent via AMI. Many of the field being sent were not
useful in the general case.
* The model for a bridge snapshot was updated to be more consistent
with the other ARI models.
Another impact of introducing subtyping was that the swagger-codegen
documentation generator was insufficient (at least until it catches up
with Swagger 1.2). I wanted it to be easier to generate docs for the API
anyways, so I ported the wiki pages to use the Asterisk Swagger
generator. In the process, I was able to clean up many of the model
links, which would occasionally give inconsistent results on the wiki. I
also added error responses to the wiki docs, making the wiki
documentation more complete.
Finally, since Stasis-HTTP will now be named Asterisk REST Interface
(ARI), any new functions and files I created carry the ari_ prefix. I
changed a few stasis_http references to ari where it was non-intrusive
and made sense.
(closes issue ASTERISK-21885)
Review: https://reviewboard.asterisk.org/r/2639/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393529 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-07-03 16:32:41 +00:00
# if defined(AST_DEVMODE)
code = response - > response_code ;
switch ( code ) {
2013-07-23 14:57:03 +00:00
case 0 : /* Implementation is still a stub, or the code wasn't set */
is_valid = response - > message = = NULL ;
break ;
case 500 : /* Internal Server Error */
case 501 : /* Not Implemented */
bridging: Fix multiple bridging issues causing SEGVs and FRACKs.
Issues:
* The bridging core allowed multiple bridges to be created with the same
unique bridgeId at the same time. Only the last bridge created with the
duplicate name was actually saved to the core bridges container.
* The bridging core was creating a stasis topic for the bridge and saving it
in the bridge->topic field but not increasing its reference count. In the
case where two bridges were created with the same uniqueid (which is also
the topic name), the second bridge would get the _existing_ topic the first
bridge created. When the first bridge was destroyed, it would take the
topic with it so when the second bridge attempted to publish a message to
it it either FRACKed or SEGVd.
* The bridge destructor, which also destroys the bridge topic, is run from the
bridge manager thread not the caller's thread. This makes it possible for
an ARI developer to create a new one with the same uniqueid believing the
old one was destroyed when, in fact, the old one's destructor hadn't
completed. This could cause the new bridge to get the old one's topic just
before the topic was destroyed. When the new bridge attempted to publish
a message on that topic, asterisk could either FRACK or SEGV.
* The ARI bridges resource also allowed multiple bridges to be created with
the same uniqueid but it kept the duplicate bridges in its app_bridges
container. This created a situation where if you added two bridges with
the same "bridge1" uniqueid, all operations on "bridge1" were performed on
the first bridge created and the second was basically orphaned. If you
attempted to delete what you thought was the second bridge, you actually
deleted the first one created.
Changes:
* A new API `ast_bridge_topic_exists(uniqueid)` was created to determine if
a topic already exists for a bridge.
* `bridge_base_init()` in bridge.c and `ast_ari_bridges_create()` in
resource_bridges.c now call `ast_bridge_topic_exists(uniqueid)` to check
if a bridge with the requested uniqueid already exists and will fail if it
does.
* `bridge_register()` in bridges.c now checks the core bridges container to
make sure a bridge doesn't already exist with the requested uniqueid.
Although most callers of `bridge_register()` will have already called
`bridge_base_init()`, which will now fail on duplicate bridges, there
is no guarantee of this so we must check again.
* The core bridges container allocation was changed to reject duplicate
uniqueids instead of silently replacing an existing one. This is a "belt
and suspenders" check.
* A global mutex was added to bridge.c to prevent concurrent calls to
`bridge_base_init()` and `bridge_register()`.
* Even though you can no longer create multiple bridges with the same uniqueid
at the same time, it's still possible that the bridge topic might be
destroyed while a second bridge with the same uniqueid was trying to use
it. To address this, the bridging core now increments the reference count
on bridge->topic when a bridge is created and decrements it when the
bridge is destroyed.
* `bridge_create_common()` in res_stasis.c now checks the stasis app_bridges
container to make sure a bridge with the requested uniqueid doesn't already
exist. This may seem like overkill but there are so many entrypoints to
bridge creation that we need to be safe and catch issues as soon in the
process as possible.
* The stasis app_bridges container allocation was changed to reject duplicate
uniqueids instead of adding them. This is a "belt and suspenders" check.
* The `bridge show all` CLI command now shows the bridge name as well as the
bridge id.
* Response code 409 "Conflict" was added as a possible response from the ARI
bridge create resources to signal that a bridge with the requested uniqueid
already exists.
* Additional debugging was added to multiple bridging and stasis files.
Resolves: #211
2025-01-22 13:52:33 -07:00
case 409 : /* Bridge with the same bridgeId already exists */
Update events to use Swagger 1.3 subtyping, and related aftermath
This patch started with the simple idea of changing the /events data
model to be more sane. The original model would send out events like:
{ "stasis_start": { "args": [], "channel": { ... } } }
The event discriminator was the field name instead of being a value in
the object, due to limitations in how Swagger 1.1 could model objects.
While technically sufficient in communicating event information, it was
really difficult to deal with in terms of client side JSON handling.
This patch takes advantage of a proposed extension[1] to Swagger which
allows type variance through the use of a discriminator field. This had
a domino effect that made this a surprisingly large patch.
[1]: https://groups.google.com/d/msg/wordnik-api/EC3rGajE0os/ey_5dBI_jWcJ
In changing the models, I also had to change the swagger_model.py
processor so it can handle the type discriminator and subtyping. I took
that a big step forward, and using that information to generate an
ari_model module, which can validate a JSON object against the Swagger
model.
The REST and WebSocket generators were changed to take advantage of the
validators. If compiled with AST_DEVMODE enabled, JSON objects that
don't match their corresponding models will not be sent out. For REST
API calls, a 500 Internal Server response is sent. For WebSockets, the
invalid JSON message is replaced with an error message.
Since this took over about half of the job of the existing JSON
generators, and the .to_json virtual function on messages took over the
other half, I reluctantly removed the generators.
The validators turned up all sorts of errors and inconsistencies in our
data models, and the code. These were cleaned up, with checks in the
code generator avoid some of the consistency problems in the future.
* The model for a channel snapshot was trimmed down to match the
information sent via AMI. Many of the field being sent were not
useful in the general case.
* The model for a bridge snapshot was updated to be more consistent
with the other ARI models.
Another impact of introducing subtyping was that the swagger-codegen
documentation generator was insufficient (at least until it catches up
with Swagger 1.2). I wanted it to be easier to generate docs for the API
anyways, so I ported the wiki pages to use the Asterisk Swagger
generator. In the process, I was able to clean up many of the model
links, which would occasionally give inconsistent results on the wiki. I
also added error responses to the wiki docs, making the wiki
documentation more complete.
Finally, since Stasis-HTTP will now be named Asterisk REST Interface
(ARI), any new functions and files I created carry the ari_ prefix. I
changed a few stasis_http references to ari where it was non-intrusive
and made sense.
(closes issue ASTERISK-21885)
Review: https://reviewboard.asterisk.org/r/2639/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393529 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-07-03 16:32:41 +00:00
is_valid = 1 ;
break ;
default :
if ( 200 < = code & & code < = 299 ) {
2013-07-27 23:11:02 +00:00
is_valid = ast_ari_validate_bridge (
Update events to use Swagger 1.3 subtyping, and related aftermath
This patch started with the simple idea of changing the /events data
model to be more sane. The original model would send out events like:
{ "stasis_start": { "args": [], "channel": { ... } } }
The event discriminator was the field name instead of being a value in
the object, due to limitations in how Swagger 1.1 could model objects.
While technically sufficient in communicating event information, it was
really difficult to deal with in terms of client side JSON handling.
This patch takes advantage of a proposed extension[1] to Swagger which
allows type variance through the use of a discriminator field. This had
a domino effect that made this a surprisingly large patch.
[1]: https://groups.google.com/d/msg/wordnik-api/EC3rGajE0os/ey_5dBI_jWcJ
In changing the models, I also had to change the swagger_model.py
processor so it can handle the type discriminator and subtyping. I took
that a big step forward, and using that information to generate an
ari_model module, which can validate a JSON object against the Swagger
model.
The REST and WebSocket generators were changed to take advantage of the
validators. If compiled with AST_DEVMODE enabled, JSON objects that
don't match their corresponding models will not be sent out. For REST
API calls, a 500 Internal Server response is sent. For WebSockets, the
invalid JSON message is replaced with an error message.
Since this took over about half of the job of the existing JSON
generators, and the .to_json virtual function on messages took over the
other half, I reluctantly removed the generators.
The validators turned up all sorts of errors and inconsistencies in our
data models, and the code. These were cleaned up, with checks in the
code generator avoid some of the consistency problems in the future.
* The model for a channel snapshot was trimmed down to match the
information sent via AMI. Many of the field being sent were not
useful in the general case.
* The model for a bridge snapshot was updated to be more consistent
with the other ARI models.
Another impact of introducing subtyping was that the swagger-codegen
documentation generator was insufficient (at least until it catches up
with Swagger 1.2). I wanted it to be easier to generate docs for the API
anyways, so I ported the wiki pages to use the Asterisk Swagger
generator. In the process, I was able to clean up many of the model
links, which would occasionally give inconsistent results on the wiki. I
also added error responses to the wiki docs, making the wiki
documentation more complete.
Finally, since Stasis-HTTP will now be named Asterisk REST Interface
(ARI), any new functions and files I created carry the ari_ prefix. I
changed a few stasis_http references to ari where it was non-intrusive
and made sense.
(closes issue ASTERISK-21885)
Review: https://reviewboard.asterisk.org/r/2639/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393529 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-07-03 16:32:41 +00:00
response - > message ) ;
} else {
ast_log ( LOG_ERROR , " Invalid error response %d for /bridges \n " , code ) ;
is_valid = 0 ;
}
}
if ( ! is_valid ) {
ast_log ( LOG_ERROR , " Response validation failed for /bridges \n " ) ;
2013-07-27 23:11:02 +00:00
ast_ari_response_error ( response , 500 ,
Update events to use Swagger 1.3 subtyping, and related aftermath
This patch started with the simple idea of changing the /events data
model to be more sane. The original model would send out events like:
{ "stasis_start": { "args": [], "channel": { ... } } }
The event discriminator was the field name instead of being a value in
the object, due to limitations in how Swagger 1.1 could model objects.
While technically sufficient in communicating event information, it was
really difficult to deal with in terms of client side JSON handling.
This patch takes advantage of a proposed extension[1] to Swagger which
allows type variance through the use of a discriminator field. This had
a domino effect that made this a surprisingly large patch.
[1]: https://groups.google.com/d/msg/wordnik-api/EC3rGajE0os/ey_5dBI_jWcJ
In changing the models, I also had to change the swagger_model.py
processor so it can handle the type discriminator and subtyping. I took
that a big step forward, and using that information to generate an
ari_model module, which can validate a JSON object against the Swagger
model.
The REST and WebSocket generators were changed to take advantage of the
validators. If compiled with AST_DEVMODE enabled, JSON objects that
don't match their corresponding models will not be sent out. For REST
API calls, a 500 Internal Server response is sent. For WebSockets, the
invalid JSON message is replaced with an error message.
Since this took over about half of the job of the existing JSON
generators, and the .to_json virtual function on messages took over the
other half, I reluctantly removed the generators.
The validators turned up all sorts of errors and inconsistencies in our
data models, and the code. These were cleaned up, with checks in the
code generator avoid some of the consistency problems in the future.
* The model for a channel snapshot was trimmed down to match the
information sent via AMI. Many of the field being sent were not
useful in the general case.
* The model for a bridge snapshot was updated to be more consistent
with the other ARI models.
Another impact of introducing subtyping was that the swagger-codegen
documentation generator was insufficient (at least until it catches up
with Swagger 1.2). I wanted it to be easier to generate docs for the API
anyways, so I ported the wiki pages to use the Asterisk Swagger
generator. In the process, I was able to clean up many of the model
links, which would occasionally give inconsistent results on the wiki. I
also added error responses to the wiki docs, making the wiki
documentation more complete.
Finally, since Stasis-HTTP will now be named Asterisk REST Interface
(ARI), any new functions and files I created carry the ari_ prefix. I
changed a few stasis_http references to ari where it was non-intrusive
and made sense.
(closes issue ASTERISK-21885)
Review: https://reviewboard.asterisk.org/r/2639/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393529 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-07-03 16:32:41 +00:00
" Internal Server Error " , " Response validation failed " ) ;
}
# endif /* AST_DEVMODE */
2013-08-02 14:36:32 +00:00
uniqueid: channel linkedid, ami, ari object creation with id's
Much needed was a way to assign id to objects on creation, and
much change was necessary to accomplish it. Channel uniqueids
and linkedids are split into separate string and creation time
components without breaking linkedid propgation. This allowed
the uniqueid to be specified by the user interface - and those
values are now carried through to channel creation, adding the
assignedids value to every function in the chain including the
channel drivers. For local channels, the second channel can be
specified or left to default to a ;2 suffix of first. In ARI,
bridge, playback, and snoop objects can also be created with a
specified uniqueid.
Along the way, the args order to allocating channels was fixed
in chan_mgcp and chan_gtalk, and linkedid is no longer lost as
masquerade occurs.
(closes issue ASTERISK-23120)
Review: https://reviewboard.asterisk.org/r/3191/
........
Merged revisions 410157 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410158 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-03-07 15:47:55 +00:00
fin : __attribute__ ( ( unused ) )
return ;
}
2015-01-27 17:21:03 +00:00
int ast_ari_bridges_create_with_id_parse_body (
uniqueid: channel linkedid, ami, ari object creation with id's
Much needed was a way to assign id to objects on creation, and
much change was necessary to accomplish it. Channel uniqueids
and linkedids are split into separate string and creation time
components without breaking linkedid propgation. This allowed
the uniqueid to be specified by the user interface - and those
values are now carried through to channel creation, adding the
assignedids value to every function in the chain including the
channel drivers. For local channels, the second channel can be
specified or left to default to a ;2 suffix of first. In ARI,
bridge, playback, and snoop objects can also be created with a
specified uniqueid.
Along the way, the args order to allocating channels was fixed
in chan_mgcp and chan_gtalk, and linkedid is no longer lost as
masquerade occurs.
(closes issue ASTERISK-23120)
Review: https://reviewboard.asterisk.org/r/3191/
........
Merged revisions 410157 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410158 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-03-07 15:47:55 +00:00
struct ast_json * body ,
2015-01-27 17:21:03 +00:00
struct ast_ari_bridges_create_with_id_args * args )
uniqueid: channel linkedid, ami, ari object creation with id's
Much needed was a way to assign id to objects on creation, and
much change was necessary to accomplish it. Channel uniqueids
and linkedids are split into separate string and creation time
components without breaking linkedid propgation. This allowed
the uniqueid to be specified by the user interface - and those
values are now carried through to channel creation, adding the
assignedids value to every function in the chain including the
channel drivers. For local channels, the second channel can be
specified or left to default to a ;2 suffix of first. In ARI,
bridge, playback, and snoop objects can also be created with a
specified uniqueid.
Along the way, the args order to allocating channels was fixed
in chan_mgcp and chan_gtalk, and linkedid is no longer lost as
masquerade occurs.
(closes issue ASTERISK-23120)
Review: https://reviewboard.asterisk.org/r/3191/
........
Merged revisions 410157 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410158 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-03-07 15:47:55 +00:00
{
struct ast_json * field ;
/* Parse query parameters out of it */
field = ast_json_object_get ( body , " type " ) ;
if ( field ) {
args - > type = ast_json_string_get ( field ) ;
}
field = ast_json_object_get ( body , " name " ) ;
if ( field ) {
args - > name = ast_json_string_get ( field ) ;
}
return 0 ;
}
/*!
* \ brief Parameter parsing callback for / bridges / { bridgeId } .
2021-11-17 13:18:32 +01:00
* \ param ser TCP / TLS session object
uniqueid: channel linkedid, ami, ari object creation with id's
Much needed was a way to assign id to objects on creation, and
much change was necessary to accomplish it. Channel uniqueids
and linkedids are split into separate string and creation time
components without breaking linkedid propgation. This allowed
the uniqueid to be specified by the user interface - and those
values are now carried through to channel creation, adding the
assignedids value to every function in the chain including the
channel drivers. For local channels, the second channel can be
specified or left to default to a ;2 suffix of first. In ARI,
bridge, playback, and snoop objects can also be created with a
specified uniqueid.
Along the way, the args order to allocating channels was fixed
in chan_mgcp and chan_gtalk, and linkedid is no longer lost as
masquerade occurs.
(closes issue ASTERISK-23120)
Review: https://reviewboard.asterisk.org/r/3191/
........
Merged revisions 410157 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410158 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-03-07 15:47:55 +00:00
* \ param get_params GET parameters in the HTTP request .
* \ param path_vars Path variables extracted from the request .
* \ param headers HTTP headers .
2021-11-17 13:18:32 +01:00
* \ param body
uniqueid: channel linkedid, ami, ari object creation with id's
Much needed was a way to assign id to objects on creation, and
much change was necessary to accomplish it. Channel uniqueids
and linkedids are split into separate string and creation time
components without breaking linkedid propgation. This allowed
the uniqueid to be specified by the user interface - and those
values are now carried through to channel creation, adding the
assignedids value to every function in the chain including the
channel drivers. For local channels, the second channel can be
specified or left to default to a ;2 suffix of first. In ARI,
bridge, playback, and snoop objects can also be created with a
specified uniqueid.
Along the way, the args order to allocating channels was fixed
in chan_mgcp and chan_gtalk, and linkedid is no longer lost as
masquerade occurs.
(closes issue ASTERISK-23120)
Review: https://reviewboard.asterisk.org/r/3191/
........
Merged revisions 410157 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410158 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-03-07 15:47:55 +00:00
* \ param [ out ] response Response to the HTTP request .
*/
2015-01-27 17:21:03 +00:00
static void ast_ari_bridges_create_with_id_cb (
uniqueid: channel linkedid, ami, ari object creation with id's
Much needed was a way to assign id to objects on creation, and
much change was necessary to accomplish it. Channel uniqueids
and linkedids are split into separate string and creation time
components without breaking linkedid propgation. This allowed
the uniqueid to be specified by the user interface - and those
values are now carried through to channel creation, adding the
assignedids value to every function in the chain including the
channel drivers. For local channels, the second channel can be
specified or left to default to a ;2 suffix of first. In ARI,
bridge, playback, and snoop objects can also be created with a
specified uniqueid.
Along the way, the args order to allocating channels was fixed
in chan_mgcp and chan_gtalk, and linkedid is no longer lost as
masquerade occurs.
(closes issue ASTERISK-23120)
Review: https://reviewboard.asterisk.org/r/3191/
........
Merged revisions 410157 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410158 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-03-07 15:47:55 +00:00
struct ast_tcptls_session_instance * ser ,
struct ast_variable * get_params , struct ast_variable * path_vars ,
2017-01-19 08:05:36 -07:00
struct ast_variable * headers , struct ast_json * body , struct ast_ari_response * response )
uniqueid: channel linkedid, ami, ari object creation with id's
Much needed was a way to assign id to objects on creation, and
much change was necessary to accomplish it. Channel uniqueids
and linkedids are split into separate string and creation time
components without breaking linkedid propgation. This allowed
the uniqueid to be specified by the user interface - and those
values are now carried through to channel creation, adding the
assignedids value to every function in the chain including the
channel drivers. For local channels, the second channel can be
specified or left to default to a ;2 suffix of first. In ARI,
bridge, playback, and snoop objects can also be created with a
specified uniqueid.
Along the way, the args order to allocating channels was fixed
in chan_mgcp and chan_gtalk, and linkedid is no longer lost as
masquerade occurs.
(closes issue ASTERISK-23120)
Review: https://reviewboard.asterisk.org/r/3191/
........
Merged revisions 410157 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410158 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-03-07 15:47:55 +00:00
{
2015-01-27 17:21:03 +00:00
struct ast_ari_bridges_create_with_id_args args = { } ;
uniqueid: channel linkedid, ami, ari object creation with id's
Much needed was a way to assign id to objects on creation, and
much change was necessary to accomplish it. Channel uniqueids
and linkedids are split into separate string and creation time
components without breaking linkedid propgation. This allowed
the uniqueid to be specified by the user interface - and those
values are now carried through to channel creation, adding the
assignedids value to every function in the chain including the
channel drivers. For local channels, the second channel can be
specified or left to default to a ;2 suffix of first. In ARI,
bridge, playback, and snoop objects can also be created with a
specified uniqueid.
Along the way, the args order to allocating channels was fixed
in chan_mgcp and chan_gtalk, and linkedid is no longer lost as
masquerade occurs.
(closes issue ASTERISK-23120)
Review: https://reviewboard.asterisk.org/r/3191/
........
Merged revisions 410157 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410158 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-03-07 15:47:55 +00:00
struct ast_variable * i ;
# if defined(AST_DEVMODE)
int is_valid ;
int code ;
# endif /* AST_DEVMODE */
for ( i = get_params ; i ; i = i - > next ) {
if ( strcmp ( i - > name , " type " ) = = 0 ) {
args . type = ( i - > value ) ;
} else
if ( strcmp ( i - > name , " name " ) = = 0 ) {
args . name = ( i - > value ) ;
} else
{ }
}
for ( i = path_vars ; i ; i = i - > next ) {
if ( strcmp ( i - > name , " bridgeId " ) = = 0 ) {
args . bridge_id = ( i - > value ) ;
} else
{ }
}
2015-01-27 17:21:03 +00:00
if ( ast_ari_bridges_create_with_id_parse_body ( body , & args ) ) {
uniqueid: channel linkedid, ami, ari object creation with id's
Much needed was a way to assign id to objects on creation, and
much change was necessary to accomplish it. Channel uniqueids
and linkedids are split into separate string and creation time
components without breaking linkedid propgation. This allowed
the uniqueid to be specified by the user interface - and those
values are now carried through to channel creation, adding the
assignedids value to every function in the chain including the
channel drivers. For local channels, the second channel can be
specified or left to default to a ;2 suffix of first. In ARI,
bridge, playback, and snoop objects can also be created with a
specified uniqueid.
Along the way, the args order to allocating channels was fixed
in chan_mgcp and chan_gtalk, and linkedid is no longer lost as
masquerade occurs.
(closes issue ASTERISK-23120)
Review: https://reviewboard.asterisk.org/r/3191/
........
Merged revisions 410157 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410158 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-03-07 15:47:55 +00:00
ast_ari_response_alloc_failed ( response ) ;
goto fin ;
}
2015-01-27 17:21:03 +00:00
ast_ari_bridges_create_with_id ( headers , & args , response ) ;
uniqueid: channel linkedid, ami, ari object creation with id's
Much needed was a way to assign id to objects on creation, and
much change was necessary to accomplish it. Channel uniqueids
and linkedids are split into separate string and creation time
components without breaking linkedid propgation. This allowed
the uniqueid to be specified by the user interface - and those
values are now carried through to channel creation, adding the
assignedids value to every function in the chain including the
channel drivers. For local channels, the second channel can be
specified or left to default to a ;2 suffix of first. In ARI,
bridge, playback, and snoop objects can also be created with a
specified uniqueid.
Along the way, the args order to allocating channels was fixed
in chan_mgcp and chan_gtalk, and linkedid is no longer lost as
masquerade occurs.
(closes issue ASTERISK-23120)
Review: https://reviewboard.asterisk.org/r/3191/
........
Merged revisions 410157 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410158 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-03-07 15:47:55 +00:00
# if defined(AST_DEVMODE)
code = response - > response_code ;
switch ( code ) {
case 0 : /* Implementation is still a stub, or the code wasn't set */
is_valid = response - > message = = NULL ;
break ;
case 500 : /* Internal Server Error */
case 501 : /* Not Implemented */
bridging: Fix multiple bridging issues causing SEGVs and FRACKs.
Issues:
* The bridging core allowed multiple bridges to be created with the same
unique bridgeId at the same time. Only the last bridge created with the
duplicate name was actually saved to the core bridges container.
* The bridging core was creating a stasis topic for the bridge and saving it
in the bridge->topic field but not increasing its reference count. In the
case where two bridges were created with the same uniqueid (which is also
the topic name), the second bridge would get the _existing_ topic the first
bridge created. When the first bridge was destroyed, it would take the
topic with it so when the second bridge attempted to publish a message to
it it either FRACKed or SEGVd.
* The bridge destructor, which also destroys the bridge topic, is run from the
bridge manager thread not the caller's thread. This makes it possible for
an ARI developer to create a new one with the same uniqueid believing the
old one was destroyed when, in fact, the old one's destructor hadn't
completed. This could cause the new bridge to get the old one's topic just
before the topic was destroyed. When the new bridge attempted to publish
a message on that topic, asterisk could either FRACK or SEGV.
* The ARI bridges resource also allowed multiple bridges to be created with
the same uniqueid but it kept the duplicate bridges in its app_bridges
container. This created a situation where if you added two bridges with
the same "bridge1" uniqueid, all operations on "bridge1" were performed on
the first bridge created and the second was basically orphaned. If you
attempted to delete what you thought was the second bridge, you actually
deleted the first one created.
Changes:
* A new API `ast_bridge_topic_exists(uniqueid)` was created to determine if
a topic already exists for a bridge.
* `bridge_base_init()` in bridge.c and `ast_ari_bridges_create()` in
resource_bridges.c now call `ast_bridge_topic_exists(uniqueid)` to check
if a bridge with the requested uniqueid already exists and will fail if it
does.
* `bridge_register()` in bridges.c now checks the core bridges container to
make sure a bridge doesn't already exist with the requested uniqueid.
Although most callers of `bridge_register()` will have already called
`bridge_base_init()`, which will now fail on duplicate bridges, there
is no guarantee of this so we must check again.
* The core bridges container allocation was changed to reject duplicate
uniqueids instead of silently replacing an existing one. This is a "belt
and suspenders" check.
* A global mutex was added to bridge.c to prevent concurrent calls to
`bridge_base_init()` and `bridge_register()`.
* Even though you can no longer create multiple bridges with the same uniqueid
at the same time, it's still possible that the bridge topic might be
destroyed while a second bridge with the same uniqueid was trying to use
it. To address this, the bridging core now increments the reference count
on bridge->topic when a bridge is created and decrements it when the
bridge is destroyed.
* `bridge_create_common()` in res_stasis.c now checks the stasis app_bridges
container to make sure a bridge with the requested uniqueid doesn't already
exist. This may seem like overkill but there are so many entrypoints to
bridge creation that we need to be safe and catch issues as soon in the
process as possible.
* The stasis app_bridges container allocation was changed to reject duplicate
uniqueids instead of adding them. This is a "belt and suspenders" check.
* The `bridge show all` CLI command now shows the bridge name as well as the
bridge id.
* Response code 409 "Conflict" was added as a possible response from the ARI
bridge create resources to signal that a bridge with the requested uniqueid
already exists.
* Additional debugging was added to multiple bridging and stasis files.
Resolves: #211
2025-01-22 13:52:33 -07:00
case 409 : /* Bridge with the same bridgeId already exists */
uniqueid: channel linkedid, ami, ari object creation with id's
Much needed was a way to assign id to objects on creation, and
much change was necessary to accomplish it. Channel uniqueids
and linkedids are split into separate string and creation time
components without breaking linkedid propgation. This allowed
the uniqueid to be specified by the user interface - and those
values are now carried through to channel creation, adding the
assignedids value to every function in the chain including the
channel drivers. For local channels, the second channel can be
specified or left to default to a ;2 suffix of first. In ARI,
bridge, playback, and snoop objects can also be created with a
specified uniqueid.
Along the way, the args order to allocating channels was fixed
in chan_mgcp and chan_gtalk, and linkedid is no longer lost as
masquerade occurs.
(closes issue ASTERISK-23120)
Review: https://reviewboard.asterisk.org/r/3191/
........
Merged revisions 410157 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410158 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-03-07 15:47:55 +00:00
is_valid = 1 ;
break ;
default :
if ( 200 < = code & & code < = 299 ) {
is_valid = ast_ari_validate_bridge (
response - > message ) ;
} else {
ast_log ( LOG_ERROR , " Invalid error response %d for /bridges/{bridgeId} \n " , code ) ;
is_valid = 0 ;
}
}
if ( ! is_valid ) {
ast_log ( LOG_ERROR , " Response validation failed for /bridges/{bridgeId} \n " ) ;
ast_ari_response_error ( response , 500 ,
" Internal Server Error " , " Response validation failed " ) ;
}
# endif /* AST_DEVMODE */
2013-08-02 14:36:32 +00:00
fin : __attribute__ ( ( unused ) )
return ;
2013-04-22 14:58:53 +00:00
}
/*!
* \ brief Parameter parsing callback for / bridges / { bridgeId } .
2021-11-17 13:18:32 +01:00
* \ param ser TCP / TLS session object
2013-04-22 14:58:53 +00:00
* \ param get_params GET parameters in the HTTP request .
* \ param path_vars Path variables extracted from the request .
* \ param headers HTTP headers .
2021-11-17 13:18:32 +01:00
* \ param body
2013-04-22 14:58:53 +00:00
* \ param [ out ] response Response to the HTTP request .
*/
2013-11-07 21:10:31 +00:00
static void ast_ari_bridges_get_cb (
2013-11-27 15:48:39 +00:00
struct ast_tcptls_session_instance * ser ,
Update events to use Swagger 1.3 subtyping, and related aftermath
This patch started with the simple idea of changing the /events data
model to be more sane. The original model would send out events like:
{ "stasis_start": { "args": [], "channel": { ... } } }
The event discriminator was the field name instead of being a value in
the object, due to limitations in how Swagger 1.1 could model objects.
While technically sufficient in communicating event information, it was
really difficult to deal with in terms of client side JSON handling.
This patch takes advantage of a proposed extension[1] to Swagger which
allows type variance through the use of a discriminator field. This had
a domino effect that made this a surprisingly large patch.
[1]: https://groups.google.com/d/msg/wordnik-api/EC3rGajE0os/ey_5dBI_jWcJ
In changing the models, I also had to change the swagger_model.py
processor so it can handle the type discriminator and subtyping. I took
that a big step forward, and using that information to generate an
ari_model module, which can validate a JSON object against the Swagger
model.
The REST and WebSocket generators were changed to take advantage of the
validators. If compiled with AST_DEVMODE enabled, JSON objects that
don't match their corresponding models will not be sent out. For REST
API calls, a 500 Internal Server response is sent. For WebSockets, the
invalid JSON message is replaced with an error message.
Since this took over about half of the job of the existing JSON
generators, and the .to_json virtual function on messages took over the
other half, I reluctantly removed the generators.
The validators turned up all sorts of errors and inconsistencies in our
data models, and the code. These were cleaned up, with checks in the
code generator avoid some of the consistency problems in the future.
* The model for a channel snapshot was trimmed down to match the
information sent via AMI. Many of the field being sent were not
useful in the general case.
* The model for a bridge snapshot was updated to be more consistent
with the other ARI models.
Another impact of introducing subtyping was that the swagger-codegen
documentation generator was insufficient (at least until it catches up
with Swagger 1.2). I wanted it to be easier to generate docs for the API
anyways, so I ported the wiki pages to use the Asterisk Swagger
generator. In the process, I was able to clean up many of the model
links, which would occasionally give inconsistent results on the wiki. I
also added error responses to the wiki docs, making the wiki
documentation more complete.
Finally, since Stasis-HTTP will now be named Asterisk REST Interface
(ARI), any new functions and files I created carry the ari_ prefix. I
changed a few stasis_http references to ari where it was non-intrusive
and made sense.
(closes issue ASTERISK-21885)
Review: https://reviewboard.asterisk.org/r/2639/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393529 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-07-03 16:32:41 +00:00
struct ast_variable * get_params , struct ast_variable * path_vars ,
2017-01-19 08:05:36 -07:00
struct ast_variable * headers , struct ast_json * body , struct ast_ari_response * response )
2013-04-22 14:58:53 +00:00
{
2013-11-07 21:10:31 +00:00
struct ast_ari_bridges_get_args args = { } ;
2013-08-02 14:36:32 +00:00
struct ast_variable * i ;
Update events to use Swagger 1.3 subtyping, and related aftermath
This patch started with the simple idea of changing the /events data
model to be more sane. The original model would send out events like:
{ "stasis_start": { "args": [], "channel": { ... } } }
The event discriminator was the field name instead of being a value in
the object, due to limitations in how Swagger 1.1 could model objects.
While technically sufficient in communicating event information, it was
really difficult to deal with in terms of client side JSON handling.
This patch takes advantage of a proposed extension[1] to Swagger which
allows type variance through the use of a discriminator field. This had
a domino effect that made this a surprisingly large patch.
[1]: https://groups.google.com/d/msg/wordnik-api/EC3rGajE0os/ey_5dBI_jWcJ
In changing the models, I also had to change the swagger_model.py
processor so it can handle the type discriminator and subtyping. I took
that a big step forward, and using that information to generate an
ari_model module, which can validate a JSON object against the Swagger
model.
The REST and WebSocket generators were changed to take advantage of the
validators. If compiled with AST_DEVMODE enabled, JSON objects that
don't match their corresponding models will not be sent out. For REST
API calls, a 500 Internal Server response is sent. For WebSockets, the
invalid JSON message is replaced with an error message.
Since this took over about half of the job of the existing JSON
generators, and the .to_json virtual function on messages took over the
other half, I reluctantly removed the generators.
The validators turned up all sorts of errors and inconsistencies in our
data models, and the code. These were cleaned up, with checks in the
code generator avoid some of the consistency problems in the future.
* The model for a channel snapshot was trimmed down to match the
information sent via AMI. Many of the field being sent were not
useful in the general case.
* The model for a bridge snapshot was updated to be more consistent
with the other ARI models.
Another impact of introducing subtyping was that the swagger-codegen
documentation generator was insufficient (at least until it catches up
with Swagger 1.2). I wanted it to be easier to generate docs for the API
anyways, so I ported the wiki pages to use the Asterisk Swagger
generator. In the process, I was able to clean up many of the model
links, which would occasionally give inconsistent results on the wiki. I
also added error responses to the wiki docs, making the wiki
documentation more complete.
Finally, since Stasis-HTTP will now be named Asterisk REST Interface
(ARI), any new functions and files I created carry the ari_ prefix. I
changed a few stasis_http references to ari where it was non-intrusive
and made sense.
(closes issue ASTERISK-21885)
Review: https://reviewboard.asterisk.org/r/2639/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393529 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-07-03 16:32:41 +00:00
# if defined(AST_DEVMODE)
int is_valid ;
int code ;
# endif /* AST_DEVMODE */
2013-04-22 14:58:53 +00:00
for ( i = path_vars ; i ; i = i - > next ) {
if ( strcmp ( i - > name , " bridgeId " ) = = 0 ) {
args . bridge_id = ( i - > value ) ;
} else
{ }
}
2013-11-07 21:10:31 +00:00
ast_ari_bridges_get ( headers , & args , response ) ;
Update events to use Swagger 1.3 subtyping, and related aftermath
This patch started with the simple idea of changing the /events data
model to be more sane. The original model would send out events like:
{ "stasis_start": { "args": [], "channel": { ... } } }
The event discriminator was the field name instead of being a value in
the object, due to limitations in how Swagger 1.1 could model objects.
While technically sufficient in communicating event information, it was
really difficult to deal with in terms of client side JSON handling.
This patch takes advantage of a proposed extension[1] to Swagger which
allows type variance through the use of a discriminator field. This had
a domino effect that made this a surprisingly large patch.
[1]: https://groups.google.com/d/msg/wordnik-api/EC3rGajE0os/ey_5dBI_jWcJ
In changing the models, I also had to change the swagger_model.py
processor so it can handle the type discriminator and subtyping. I took
that a big step forward, and using that information to generate an
ari_model module, which can validate a JSON object against the Swagger
model.
The REST and WebSocket generators were changed to take advantage of the
validators. If compiled with AST_DEVMODE enabled, JSON objects that
don't match their corresponding models will not be sent out. For REST
API calls, a 500 Internal Server response is sent. For WebSockets, the
invalid JSON message is replaced with an error message.
Since this took over about half of the job of the existing JSON
generators, and the .to_json virtual function on messages took over the
other half, I reluctantly removed the generators.
The validators turned up all sorts of errors and inconsistencies in our
data models, and the code. These were cleaned up, with checks in the
code generator avoid some of the consistency problems in the future.
* The model for a channel snapshot was trimmed down to match the
information sent via AMI. Many of the field being sent were not
useful in the general case.
* The model for a bridge snapshot was updated to be more consistent
with the other ARI models.
Another impact of introducing subtyping was that the swagger-codegen
documentation generator was insufficient (at least until it catches up
with Swagger 1.2). I wanted it to be easier to generate docs for the API
anyways, so I ported the wiki pages to use the Asterisk Swagger
generator. In the process, I was able to clean up many of the model
links, which would occasionally give inconsistent results on the wiki. I
also added error responses to the wiki docs, making the wiki
documentation more complete.
Finally, since Stasis-HTTP will now be named Asterisk REST Interface
(ARI), any new functions and files I created carry the ari_ prefix. I
changed a few stasis_http references to ari where it was non-intrusive
and made sense.
(closes issue ASTERISK-21885)
Review: https://reviewboard.asterisk.org/r/2639/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393529 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-07-03 16:32:41 +00:00
# if defined(AST_DEVMODE)
code = response - > response_code ;
switch ( code ) {
2013-07-23 14:57:03 +00:00
case 0 : /* Implementation is still a stub, or the code wasn't set */
is_valid = response - > message = = NULL ;
break ;
case 500 : /* Internal Server Error */
case 501 : /* Not Implemented */
Update events to use Swagger 1.3 subtyping, and related aftermath
This patch started with the simple idea of changing the /events data
model to be more sane. The original model would send out events like:
{ "stasis_start": { "args": [], "channel": { ... } } }
The event discriminator was the field name instead of being a value in
the object, due to limitations in how Swagger 1.1 could model objects.
While technically sufficient in communicating event information, it was
really difficult to deal with in terms of client side JSON handling.
This patch takes advantage of a proposed extension[1] to Swagger which
allows type variance through the use of a discriminator field. This had
a domino effect that made this a surprisingly large patch.
[1]: https://groups.google.com/d/msg/wordnik-api/EC3rGajE0os/ey_5dBI_jWcJ
In changing the models, I also had to change the swagger_model.py
processor so it can handle the type discriminator and subtyping. I took
that a big step forward, and using that information to generate an
ari_model module, which can validate a JSON object against the Swagger
model.
The REST and WebSocket generators were changed to take advantage of the
validators. If compiled with AST_DEVMODE enabled, JSON objects that
don't match their corresponding models will not be sent out. For REST
API calls, a 500 Internal Server response is sent. For WebSockets, the
invalid JSON message is replaced with an error message.
Since this took over about half of the job of the existing JSON
generators, and the .to_json virtual function on messages took over the
other half, I reluctantly removed the generators.
The validators turned up all sorts of errors and inconsistencies in our
data models, and the code. These were cleaned up, with checks in the
code generator avoid some of the consistency problems in the future.
* The model for a channel snapshot was trimmed down to match the
information sent via AMI. Many of the field being sent were not
useful in the general case.
* The model for a bridge snapshot was updated to be more consistent
with the other ARI models.
Another impact of introducing subtyping was that the swagger-codegen
documentation generator was insufficient (at least until it catches up
with Swagger 1.2). I wanted it to be easier to generate docs for the API
anyways, so I ported the wiki pages to use the Asterisk Swagger
generator. In the process, I was able to clean up many of the model
links, which would occasionally give inconsistent results on the wiki. I
also added error responses to the wiki docs, making the wiki
documentation more complete.
Finally, since Stasis-HTTP will now be named Asterisk REST Interface
(ARI), any new functions and files I created carry the ari_ prefix. I
changed a few stasis_http references to ari where it was non-intrusive
and made sense.
(closes issue ASTERISK-21885)
Review: https://reviewboard.asterisk.org/r/2639/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393529 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-07-03 16:32:41 +00:00
case 404 : /* Bridge not found */
is_valid = 1 ;
break ;
default :
if ( 200 < = code & & code < = 299 ) {
2013-07-27 23:11:02 +00:00
is_valid = ast_ari_validate_bridge (
Update events to use Swagger 1.3 subtyping, and related aftermath
This patch started with the simple idea of changing the /events data
model to be more sane. The original model would send out events like:
{ "stasis_start": { "args": [], "channel": { ... } } }
The event discriminator was the field name instead of being a value in
the object, due to limitations in how Swagger 1.1 could model objects.
While technically sufficient in communicating event information, it was
really difficult to deal with in terms of client side JSON handling.
This patch takes advantage of a proposed extension[1] to Swagger which
allows type variance through the use of a discriminator field. This had
a domino effect that made this a surprisingly large patch.
[1]: https://groups.google.com/d/msg/wordnik-api/EC3rGajE0os/ey_5dBI_jWcJ
In changing the models, I also had to change the swagger_model.py
processor so it can handle the type discriminator and subtyping. I took
that a big step forward, and using that information to generate an
ari_model module, which can validate a JSON object against the Swagger
model.
The REST and WebSocket generators were changed to take advantage of the
validators. If compiled with AST_DEVMODE enabled, JSON objects that
don't match their corresponding models will not be sent out. For REST
API calls, a 500 Internal Server response is sent. For WebSockets, the
invalid JSON message is replaced with an error message.
Since this took over about half of the job of the existing JSON
generators, and the .to_json virtual function on messages took over the
other half, I reluctantly removed the generators.
The validators turned up all sorts of errors and inconsistencies in our
data models, and the code. These were cleaned up, with checks in the
code generator avoid some of the consistency problems in the future.
* The model for a channel snapshot was trimmed down to match the
information sent via AMI. Many of the field being sent were not
useful in the general case.
* The model for a bridge snapshot was updated to be more consistent
with the other ARI models.
Another impact of introducing subtyping was that the swagger-codegen
documentation generator was insufficient (at least until it catches up
with Swagger 1.2). I wanted it to be easier to generate docs for the API
anyways, so I ported the wiki pages to use the Asterisk Swagger
generator. In the process, I was able to clean up many of the model
links, which would occasionally give inconsistent results on the wiki. I
also added error responses to the wiki docs, making the wiki
documentation more complete.
Finally, since Stasis-HTTP will now be named Asterisk REST Interface
(ARI), any new functions and files I created carry the ari_ prefix. I
changed a few stasis_http references to ari where it was non-intrusive
and made sense.
(closes issue ASTERISK-21885)
Review: https://reviewboard.asterisk.org/r/2639/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393529 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-07-03 16:32:41 +00:00
response - > message ) ;
} else {
ast_log ( LOG_ERROR , " Invalid error response %d for /bridges/{bridgeId} \n " , code ) ;
is_valid = 0 ;
}
}
if ( ! is_valid ) {
ast_log ( LOG_ERROR , " Response validation failed for /bridges/{bridgeId} \n " ) ;
2013-07-27 23:11:02 +00:00
ast_ari_response_error ( response , 500 ,
Update events to use Swagger 1.3 subtyping, and related aftermath
This patch started with the simple idea of changing the /events data
model to be more sane. The original model would send out events like:
{ "stasis_start": { "args": [], "channel": { ... } } }
The event discriminator was the field name instead of being a value in
the object, due to limitations in how Swagger 1.1 could model objects.
While technically sufficient in communicating event information, it was
really difficult to deal with in terms of client side JSON handling.
This patch takes advantage of a proposed extension[1] to Swagger which
allows type variance through the use of a discriminator field. This had
a domino effect that made this a surprisingly large patch.
[1]: https://groups.google.com/d/msg/wordnik-api/EC3rGajE0os/ey_5dBI_jWcJ
In changing the models, I also had to change the swagger_model.py
processor so it can handle the type discriminator and subtyping. I took
that a big step forward, and using that information to generate an
ari_model module, which can validate a JSON object against the Swagger
model.
The REST and WebSocket generators were changed to take advantage of the
validators. If compiled with AST_DEVMODE enabled, JSON objects that
don't match their corresponding models will not be sent out. For REST
API calls, a 500 Internal Server response is sent. For WebSockets, the
invalid JSON message is replaced with an error message.
Since this took over about half of the job of the existing JSON
generators, and the .to_json virtual function on messages took over the
other half, I reluctantly removed the generators.
The validators turned up all sorts of errors and inconsistencies in our
data models, and the code. These were cleaned up, with checks in the
code generator avoid some of the consistency problems in the future.
* The model for a channel snapshot was trimmed down to match the
information sent via AMI. Many of the field being sent were not
useful in the general case.
* The model for a bridge snapshot was updated to be more consistent
with the other ARI models.
Another impact of introducing subtyping was that the swagger-codegen
documentation generator was insufficient (at least until it catches up
with Swagger 1.2). I wanted it to be easier to generate docs for the API
anyways, so I ported the wiki pages to use the Asterisk Swagger
generator. In the process, I was able to clean up many of the model
links, which would occasionally give inconsistent results on the wiki. I
also added error responses to the wiki docs, making the wiki
documentation more complete.
Finally, since Stasis-HTTP will now be named Asterisk REST Interface
(ARI), any new functions and files I created carry the ari_ prefix. I
changed a few stasis_http references to ari where it was non-intrusive
and made sense.
(closes issue ASTERISK-21885)
Review: https://reviewboard.asterisk.org/r/2639/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393529 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-07-03 16:32:41 +00:00
" Internal Server Error " , " Response validation failed " ) ;
}
# endif /* AST_DEVMODE */
2013-08-02 14:36:32 +00:00
fin : __attribute__ ( ( unused ) )
return ;
2013-04-22 14:58:53 +00:00
}
/*!
* \ brief Parameter parsing callback for / bridges / { bridgeId } .
2021-11-17 13:18:32 +01:00
* \ param ser TCP / TLS session object
2013-04-22 14:58:53 +00:00
* \ param get_params GET parameters in the HTTP request .
* \ param path_vars Path variables extracted from the request .
* \ param headers HTTP headers .
2021-11-17 13:18:32 +01:00
* \ param body
2013-04-22 14:58:53 +00:00
* \ param [ out ] response Response to the HTTP request .
*/
2013-11-07 21:10:31 +00:00
static void ast_ari_bridges_destroy_cb (
2013-11-27 15:48:39 +00:00
struct ast_tcptls_session_instance * ser ,
Update events to use Swagger 1.3 subtyping, and related aftermath
This patch started with the simple idea of changing the /events data
model to be more sane. The original model would send out events like:
{ "stasis_start": { "args": [], "channel": { ... } } }
The event discriminator was the field name instead of being a value in
the object, due to limitations in how Swagger 1.1 could model objects.
While technically sufficient in communicating event information, it was
really difficult to deal with in terms of client side JSON handling.
This patch takes advantage of a proposed extension[1] to Swagger which
allows type variance through the use of a discriminator field. This had
a domino effect that made this a surprisingly large patch.
[1]: https://groups.google.com/d/msg/wordnik-api/EC3rGajE0os/ey_5dBI_jWcJ
In changing the models, I also had to change the swagger_model.py
processor so it can handle the type discriminator and subtyping. I took
that a big step forward, and using that information to generate an
ari_model module, which can validate a JSON object against the Swagger
model.
The REST and WebSocket generators were changed to take advantage of the
validators. If compiled with AST_DEVMODE enabled, JSON objects that
don't match their corresponding models will not be sent out. For REST
API calls, a 500 Internal Server response is sent. For WebSockets, the
invalid JSON message is replaced with an error message.
Since this took over about half of the job of the existing JSON
generators, and the .to_json virtual function on messages took over the
other half, I reluctantly removed the generators.
The validators turned up all sorts of errors and inconsistencies in our
data models, and the code. These were cleaned up, with checks in the
code generator avoid some of the consistency problems in the future.
* The model for a channel snapshot was trimmed down to match the
information sent via AMI. Many of the field being sent were not
useful in the general case.
* The model for a bridge snapshot was updated to be more consistent
with the other ARI models.
Another impact of introducing subtyping was that the swagger-codegen
documentation generator was insufficient (at least until it catches up
with Swagger 1.2). I wanted it to be easier to generate docs for the API
anyways, so I ported the wiki pages to use the Asterisk Swagger
generator. In the process, I was able to clean up many of the model
links, which would occasionally give inconsistent results on the wiki. I
also added error responses to the wiki docs, making the wiki
documentation more complete.
Finally, since Stasis-HTTP will now be named Asterisk REST Interface
(ARI), any new functions and files I created carry the ari_ prefix. I
changed a few stasis_http references to ari where it was non-intrusive
and made sense.
(closes issue ASTERISK-21885)
Review: https://reviewboard.asterisk.org/r/2639/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393529 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-07-03 16:32:41 +00:00
struct ast_variable * get_params , struct ast_variable * path_vars ,
2017-01-19 08:05:36 -07:00
struct ast_variable * headers , struct ast_json * body , struct ast_ari_response * response )
2013-04-22 14:58:53 +00:00
{
2013-11-07 21:10:31 +00:00
struct ast_ari_bridges_destroy_args args = { } ;
2013-08-02 14:36:32 +00:00
struct ast_variable * i ;
Update events to use Swagger 1.3 subtyping, and related aftermath
This patch started with the simple idea of changing the /events data
model to be more sane. The original model would send out events like:
{ "stasis_start": { "args": [], "channel": { ... } } }
The event discriminator was the field name instead of being a value in
the object, due to limitations in how Swagger 1.1 could model objects.
While technically sufficient in communicating event information, it was
really difficult to deal with in terms of client side JSON handling.
This patch takes advantage of a proposed extension[1] to Swagger which
allows type variance through the use of a discriminator field. This had
a domino effect that made this a surprisingly large patch.
[1]: https://groups.google.com/d/msg/wordnik-api/EC3rGajE0os/ey_5dBI_jWcJ
In changing the models, I also had to change the swagger_model.py
processor so it can handle the type discriminator and subtyping. I took
that a big step forward, and using that information to generate an
ari_model module, which can validate a JSON object against the Swagger
model.
The REST and WebSocket generators were changed to take advantage of the
validators. If compiled with AST_DEVMODE enabled, JSON objects that
don't match their corresponding models will not be sent out. For REST
API calls, a 500 Internal Server response is sent. For WebSockets, the
invalid JSON message is replaced with an error message.
Since this took over about half of the job of the existing JSON
generators, and the .to_json virtual function on messages took over the
other half, I reluctantly removed the generators.
The validators turned up all sorts of errors and inconsistencies in our
data models, and the code. These were cleaned up, with checks in the
code generator avoid some of the consistency problems in the future.
* The model for a channel snapshot was trimmed down to match the
information sent via AMI. Many of the field being sent were not
useful in the general case.
* The model for a bridge snapshot was updated to be more consistent
with the other ARI models.
Another impact of introducing subtyping was that the swagger-codegen
documentation generator was insufficient (at least until it catches up
with Swagger 1.2). I wanted it to be easier to generate docs for the API
anyways, so I ported the wiki pages to use the Asterisk Swagger
generator. In the process, I was able to clean up many of the model
links, which would occasionally give inconsistent results on the wiki. I
also added error responses to the wiki docs, making the wiki
documentation more complete.
Finally, since Stasis-HTTP will now be named Asterisk REST Interface
(ARI), any new functions and files I created carry the ari_ prefix. I
changed a few stasis_http references to ari where it was non-intrusive
and made sense.
(closes issue ASTERISK-21885)
Review: https://reviewboard.asterisk.org/r/2639/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393529 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-07-03 16:32:41 +00:00
# if defined(AST_DEVMODE)
int is_valid ;
int code ;
# endif /* AST_DEVMODE */
2013-04-22 14:58:53 +00:00
for ( i = path_vars ; i ; i = i - > next ) {
if ( strcmp ( i - > name , " bridgeId " ) = = 0 ) {
args . bridge_id = ( i - > value ) ;
} else
{ }
}
2013-11-07 21:10:31 +00:00
ast_ari_bridges_destroy ( headers , & args , response ) ;
Update events to use Swagger 1.3 subtyping, and related aftermath
This patch started with the simple idea of changing the /events data
model to be more sane. The original model would send out events like:
{ "stasis_start": { "args": [], "channel": { ... } } }
The event discriminator was the field name instead of being a value in
the object, due to limitations in how Swagger 1.1 could model objects.
While technically sufficient in communicating event information, it was
really difficult to deal with in terms of client side JSON handling.
This patch takes advantage of a proposed extension[1] to Swagger which
allows type variance through the use of a discriminator field. This had
a domino effect that made this a surprisingly large patch.
[1]: https://groups.google.com/d/msg/wordnik-api/EC3rGajE0os/ey_5dBI_jWcJ
In changing the models, I also had to change the swagger_model.py
processor so it can handle the type discriminator and subtyping. I took
that a big step forward, and using that information to generate an
ari_model module, which can validate a JSON object against the Swagger
model.
The REST and WebSocket generators were changed to take advantage of the
validators. If compiled with AST_DEVMODE enabled, JSON objects that
don't match their corresponding models will not be sent out. For REST
API calls, a 500 Internal Server response is sent. For WebSockets, the
invalid JSON message is replaced with an error message.
Since this took over about half of the job of the existing JSON
generators, and the .to_json virtual function on messages took over the
other half, I reluctantly removed the generators.
The validators turned up all sorts of errors and inconsistencies in our
data models, and the code. These were cleaned up, with checks in the
code generator avoid some of the consistency problems in the future.
* The model for a channel snapshot was trimmed down to match the
information sent via AMI. Many of the field being sent were not
useful in the general case.
* The model for a bridge snapshot was updated to be more consistent
with the other ARI models.
Another impact of introducing subtyping was that the swagger-codegen
documentation generator was insufficient (at least until it catches up
with Swagger 1.2). I wanted it to be easier to generate docs for the API
anyways, so I ported the wiki pages to use the Asterisk Swagger
generator. In the process, I was able to clean up many of the model
links, which would occasionally give inconsistent results on the wiki. I
also added error responses to the wiki docs, making the wiki
documentation more complete.
Finally, since Stasis-HTTP will now be named Asterisk REST Interface
(ARI), any new functions and files I created carry the ari_ prefix. I
changed a few stasis_http references to ari where it was non-intrusive
and made sense.
(closes issue ASTERISK-21885)
Review: https://reviewboard.asterisk.org/r/2639/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393529 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-07-03 16:32:41 +00:00
# if defined(AST_DEVMODE)
code = response - > response_code ;
switch ( code ) {
2013-07-23 14:57:03 +00:00
case 0 : /* Implementation is still a stub, or the code wasn't set */
is_valid = response - > message = = NULL ;
break ;
case 500 : /* Internal Server Error */
case 501 : /* Not Implemented */
Update events to use Swagger 1.3 subtyping, and related aftermath
This patch started with the simple idea of changing the /events data
model to be more sane. The original model would send out events like:
{ "stasis_start": { "args": [], "channel": { ... } } }
The event discriminator was the field name instead of being a value in
the object, due to limitations in how Swagger 1.1 could model objects.
While technically sufficient in communicating event information, it was
really difficult to deal with in terms of client side JSON handling.
This patch takes advantage of a proposed extension[1] to Swagger which
allows type variance through the use of a discriminator field. This had
a domino effect that made this a surprisingly large patch.
[1]: https://groups.google.com/d/msg/wordnik-api/EC3rGajE0os/ey_5dBI_jWcJ
In changing the models, I also had to change the swagger_model.py
processor so it can handle the type discriminator and subtyping. I took
that a big step forward, and using that information to generate an
ari_model module, which can validate a JSON object against the Swagger
model.
The REST and WebSocket generators were changed to take advantage of the
validators. If compiled with AST_DEVMODE enabled, JSON objects that
don't match their corresponding models will not be sent out. For REST
API calls, a 500 Internal Server response is sent. For WebSockets, the
invalid JSON message is replaced with an error message.
Since this took over about half of the job of the existing JSON
generators, and the .to_json virtual function on messages took over the
other half, I reluctantly removed the generators.
The validators turned up all sorts of errors and inconsistencies in our
data models, and the code. These were cleaned up, with checks in the
code generator avoid some of the consistency problems in the future.
* The model for a channel snapshot was trimmed down to match the
information sent via AMI. Many of the field being sent were not
useful in the general case.
* The model for a bridge snapshot was updated to be more consistent
with the other ARI models.
Another impact of introducing subtyping was that the swagger-codegen
documentation generator was insufficient (at least until it catches up
with Swagger 1.2). I wanted it to be easier to generate docs for the API
anyways, so I ported the wiki pages to use the Asterisk Swagger
generator. In the process, I was able to clean up many of the model
links, which would occasionally give inconsistent results on the wiki. I
also added error responses to the wiki docs, making the wiki
documentation more complete.
Finally, since Stasis-HTTP will now be named Asterisk REST Interface
(ARI), any new functions and files I created carry the ari_ prefix. I
changed a few stasis_http references to ari where it was non-intrusive
and made sense.
(closes issue ASTERISK-21885)
Review: https://reviewboard.asterisk.org/r/2639/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393529 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-07-03 16:32:41 +00:00
case 404 : /* Bridge not found */
is_valid = 1 ;
break ;
default :
if ( 200 < = code & & code < = 299 ) {
2013-07-27 23:11:02 +00:00
is_valid = ast_ari_validate_void (
Update events to use Swagger 1.3 subtyping, and related aftermath
This patch started with the simple idea of changing the /events data
model to be more sane. The original model would send out events like:
{ "stasis_start": { "args": [], "channel": { ... } } }
The event discriminator was the field name instead of being a value in
the object, due to limitations in how Swagger 1.1 could model objects.
While technically sufficient in communicating event information, it was
really difficult to deal with in terms of client side JSON handling.
This patch takes advantage of a proposed extension[1] to Swagger which
allows type variance through the use of a discriminator field. This had
a domino effect that made this a surprisingly large patch.
[1]: https://groups.google.com/d/msg/wordnik-api/EC3rGajE0os/ey_5dBI_jWcJ
In changing the models, I also had to change the swagger_model.py
processor so it can handle the type discriminator and subtyping. I took
that a big step forward, and using that information to generate an
ari_model module, which can validate a JSON object against the Swagger
model.
The REST and WebSocket generators were changed to take advantage of the
validators. If compiled with AST_DEVMODE enabled, JSON objects that
don't match their corresponding models will not be sent out. For REST
API calls, a 500 Internal Server response is sent. For WebSockets, the
invalid JSON message is replaced with an error message.
Since this took over about half of the job of the existing JSON
generators, and the .to_json virtual function on messages took over the
other half, I reluctantly removed the generators.
The validators turned up all sorts of errors and inconsistencies in our
data models, and the code. These were cleaned up, with checks in the
code generator avoid some of the consistency problems in the future.
* The model for a channel snapshot was trimmed down to match the
information sent via AMI. Many of the field being sent were not
useful in the general case.
* The model for a bridge snapshot was updated to be more consistent
with the other ARI models.
Another impact of introducing subtyping was that the swagger-codegen
documentation generator was insufficient (at least until it catches up
with Swagger 1.2). I wanted it to be easier to generate docs for the API
anyways, so I ported the wiki pages to use the Asterisk Swagger
generator. In the process, I was able to clean up many of the model
links, which would occasionally give inconsistent results on the wiki. I
also added error responses to the wiki docs, making the wiki
documentation more complete.
Finally, since Stasis-HTTP will now be named Asterisk REST Interface
(ARI), any new functions and files I created carry the ari_ prefix. I
changed a few stasis_http references to ari where it was non-intrusive
and made sense.
(closes issue ASTERISK-21885)
Review: https://reviewboard.asterisk.org/r/2639/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393529 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-07-03 16:32:41 +00:00
response - > message ) ;
} else {
ast_log ( LOG_ERROR , " Invalid error response %d for /bridges/{bridgeId} \n " , code ) ;
is_valid = 0 ;
}
}
if ( ! is_valid ) {
ast_log ( LOG_ERROR , " Response validation failed for /bridges/{bridgeId} \n " ) ;
2013-07-27 23:11:02 +00:00
ast_ari_response_error ( response , 500 ,
Update events to use Swagger 1.3 subtyping, and related aftermath
This patch started with the simple idea of changing the /events data
model to be more sane. The original model would send out events like:
{ "stasis_start": { "args": [], "channel": { ... } } }
The event discriminator was the field name instead of being a value in
the object, due to limitations in how Swagger 1.1 could model objects.
While technically sufficient in communicating event information, it was
really difficult to deal with in terms of client side JSON handling.
This patch takes advantage of a proposed extension[1] to Swagger which
allows type variance through the use of a discriminator field. This had
a domino effect that made this a surprisingly large patch.
[1]: https://groups.google.com/d/msg/wordnik-api/EC3rGajE0os/ey_5dBI_jWcJ
In changing the models, I also had to change the swagger_model.py
processor so it can handle the type discriminator and subtyping. I took
that a big step forward, and using that information to generate an
ari_model module, which can validate a JSON object against the Swagger
model.
The REST and WebSocket generators were changed to take advantage of the
validators. If compiled with AST_DEVMODE enabled, JSON objects that
don't match their corresponding models will not be sent out. For REST
API calls, a 500 Internal Server response is sent. For WebSockets, the
invalid JSON message is replaced with an error message.
Since this took over about half of the job of the existing JSON
generators, and the .to_json virtual function on messages took over the
other half, I reluctantly removed the generators.
The validators turned up all sorts of errors and inconsistencies in our
data models, and the code. These were cleaned up, with checks in the
code generator avoid some of the consistency problems in the future.
* The model for a channel snapshot was trimmed down to match the
information sent via AMI. Many of the field being sent were not
useful in the general case.
* The model for a bridge snapshot was updated to be more consistent
with the other ARI models.
Another impact of introducing subtyping was that the swagger-codegen
documentation generator was insufficient (at least until it catches up
with Swagger 1.2). I wanted it to be easier to generate docs for the API
anyways, so I ported the wiki pages to use the Asterisk Swagger
generator. In the process, I was able to clean up many of the model
links, which would occasionally give inconsistent results on the wiki. I
also added error responses to the wiki docs, making the wiki
documentation more complete.
Finally, since Stasis-HTTP will now be named Asterisk REST Interface
(ARI), any new functions and files I created carry the ari_ prefix. I
changed a few stasis_http references to ari where it was non-intrusive
and made sense.
(closes issue ASTERISK-21885)
Review: https://reviewboard.asterisk.org/r/2639/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393529 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-07-03 16:32:41 +00:00
" Internal Server Error " , " Response validation failed " ) ;
}
# endif /* AST_DEVMODE */
2013-08-02 14:36:32 +00:00
fin : __attribute__ ( ( unused ) )
return ;
2013-04-22 14:58:53 +00:00
}
2014-01-21 14:27:21 +00:00
int ast_ari_bridges_add_channel_parse_body (
struct ast_json * body ,
struct ast_ari_bridges_add_channel_args * args )
{
struct ast_json * field ;
/* Parse query parameters out of it */
field = ast_json_object_get ( body , " channel " ) ;
if ( field ) {
/* If they were silly enough to both pass in a query param and a
* JSON body , free up the query value .
*/
ast_free ( args - > channel ) ;
if ( ast_json_typeof ( field ) = = AST_JSON_ARRAY ) {
/* Multiple param passed as array */
size_t i ;
args - > channel_count = ast_json_array_size ( field ) ;
args - > channel = ast_malloc ( sizeof ( * args - > channel ) * args - > channel_count ) ;
if ( ! args - > channel ) {
return - 1 ;
}
for ( i = 0 ; i < args - > channel_count ; + + i ) {
args - > channel [ i ] = ast_json_string_get ( ast_json_array_get ( field , i ) ) ;
}
} else {
/* Multiple param passed as single value */
args - > channel_count = 1 ;
args - > channel = ast_malloc ( sizeof ( * args - > channel ) * args - > channel_count ) ;
if ( ! args - > channel ) {
return - 1 ;
}
args - > channel [ 0 ] = ast_json_string_get ( field ) ;
}
}
field = ast_json_object_get ( body , " role " ) ;
if ( field ) {
args - > role = ast_json_string_get ( field ) ;
}
2017-10-06 21:48:48 -04:00
field = ast_json_object_get ( body , " absorbDTMF " ) ;
if ( field ) {
args - > absorb_dtmf = ast_json_is_true ( field ) ;
}
field = ast_json_object_get ( body , " mute " ) ;
if ( field ) {
args - > mute = ast_json_is_true ( field ) ;
}
2019-11-22 15:32:42 +01:00
field = ast_json_object_get ( body , " inhibitConnectedLineUpdates " ) ;
if ( field ) {
args - > inhibit_connected_line_updates = ast_json_is_true ( field ) ;
}
2014-01-21 14:27:21 +00:00
return 0 ;
}
2013-04-22 14:58:53 +00:00
/*!
* \ brief Parameter parsing callback for / bridges / { bridgeId } / addChannel .
2021-11-17 13:18:32 +01:00
* \ param ser TCP / TLS session object
2013-04-22 14:58:53 +00:00
* \ param get_params GET parameters in the HTTP request .
* \ param path_vars Path variables extracted from the request .
* \ param headers HTTP headers .
2021-11-17 13:18:32 +01:00
* \ param body
2013-04-22 14:58:53 +00:00
* \ param [ out ] response Response to the HTTP request .
*/
2013-11-07 21:10:31 +00:00
static void ast_ari_bridges_add_channel_cb (
2013-11-27 15:48:39 +00:00
struct ast_tcptls_session_instance * ser ,
Update events to use Swagger 1.3 subtyping, and related aftermath
This patch started with the simple idea of changing the /events data
model to be more sane. The original model would send out events like:
{ "stasis_start": { "args": [], "channel": { ... } } }
The event discriminator was the field name instead of being a value in
the object, due to limitations in how Swagger 1.1 could model objects.
While technically sufficient in communicating event information, it was
really difficult to deal with in terms of client side JSON handling.
This patch takes advantage of a proposed extension[1] to Swagger which
allows type variance through the use of a discriminator field. This had
a domino effect that made this a surprisingly large patch.
[1]: https://groups.google.com/d/msg/wordnik-api/EC3rGajE0os/ey_5dBI_jWcJ
In changing the models, I also had to change the swagger_model.py
processor so it can handle the type discriminator and subtyping. I took
that a big step forward, and using that information to generate an
ari_model module, which can validate a JSON object against the Swagger
model.
The REST and WebSocket generators were changed to take advantage of the
validators. If compiled with AST_DEVMODE enabled, JSON objects that
don't match their corresponding models will not be sent out. For REST
API calls, a 500 Internal Server response is sent. For WebSockets, the
invalid JSON message is replaced with an error message.
Since this took over about half of the job of the existing JSON
generators, and the .to_json virtual function on messages took over the
other half, I reluctantly removed the generators.
The validators turned up all sorts of errors and inconsistencies in our
data models, and the code. These were cleaned up, with checks in the
code generator avoid some of the consistency problems in the future.
* The model for a channel snapshot was trimmed down to match the
information sent via AMI. Many of the field being sent were not
useful in the general case.
* The model for a bridge snapshot was updated to be more consistent
with the other ARI models.
Another impact of introducing subtyping was that the swagger-codegen
documentation generator was insufficient (at least until it catches up
with Swagger 1.2). I wanted it to be easier to generate docs for the API
anyways, so I ported the wiki pages to use the Asterisk Swagger
generator. In the process, I was able to clean up many of the model
links, which would occasionally give inconsistent results on the wiki. I
also added error responses to the wiki docs, making the wiki
documentation more complete.
Finally, since Stasis-HTTP will now be named Asterisk REST Interface
(ARI), any new functions and files I created carry the ari_ prefix. I
changed a few stasis_http references to ari where it was non-intrusive
and made sense.
(closes issue ASTERISK-21885)
Review: https://reviewboard.asterisk.org/r/2639/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393529 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-07-03 16:32:41 +00:00
struct ast_variable * get_params , struct ast_variable * path_vars ,
2017-01-19 08:05:36 -07:00
struct ast_variable * headers , struct ast_json * body , struct ast_ari_response * response )
2013-04-22 14:58:53 +00:00
{
2013-11-07 21:10:31 +00:00
struct ast_ari_bridges_add_channel_args args = { } ;
2013-08-02 14:36:32 +00:00
struct ast_variable * i ;
Update events to use Swagger 1.3 subtyping, and related aftermath
This patch started with the simple idea of changing the /events data
model to be more sane. The original model would send out events like:
{ "stasis_start": { "args": [], "channel": { ... } } }
The event discriminator was the field name instead of being a value in
the object, due to limitations in how Swagger 1.1 could model objects.
While technically sufficient in communicating event information, it was
really difficult to deal with in terms of client side JSON handling.
This patch takes advantage of a proposed extension[1] to Swagger which
allows type variance through the use of a discriminator field. This had
a domino effect that made this a surprisingly large patch.
[1]: https://groups.google.com/d/msg/wordnik-api/EC3rGajE0os/ey_5dBI_jWcJ
In changing the models, I also had to change the swagger_model.py
processor so it can handle the type discriminator and subtyping. I took
that a big step forward, and using that information to generate an
ari_model module, which can validate a JSON object against the Swagger
model.
The REST and WebSocket generators were changed to take advantage of the
validators. If compiled with AST_DEVMODE enabled, JSON objects that
don't match their corresponding models will not be sent out. For REST
API calls, a 500 Internal Server response is sent. For WebSockets, the
invalid JSON message is replaced with an error message.
Since this took over about half of the job of the existing JSON
generators, and the .to_json virtual function on messages took over the
other half, I reluctantly removed the generators.
The validators turned up all sorts of errors and inconsistencies in our
data models, and the code. These were cleaned up, with checks in the
code generator avoid some of the consistency problems in the future.
* The model for a channel snapshot was trimmed down to match the
information sent via AMI. Many of the field being sent were not
useful in the general case.
* The model for a bridge snapshot was updated to be more consistent
with the other ARI models.
Another impact of introducing subtyping was that the swagger-codegen
documentation generator was insufficient (at least until it catches up
with Swagger 1.2). I wanted it to be easier to generate docs for the API
anyways, so I ported the wiki pages to use the Asterisk Swagger
generator. In the process, I was able to clean up many of the model
links, which would occasionally give inconsistent results on the wiki. I
also added error responses to the wiki docs, making the wiki
documentation more complete.
Finally, since Stasis-HTTP will now be named Asterisk REST Interface
(ARI), any new functions and files I created carry the ari_ prefix. I
changed a few stasis_http references to ari where it was non-intrusive
and made sense.
(closes issue ASTERISK-21885)
Review: https://reviewboard.asterisk.org/r/2639/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393529 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-07-03 16:32:41 +00:00
# if defined(AST_DEVMODE)
int is_valid ;
int code ;
# endif /* AST_DEVMODE */
2013-04-22 14:58:53 +00:00
for ( i = get_params ; i ; i = i - > next ) {
if ( strcmp ( i - > name , " channel " ) = = 0 ) {
2013-08-02 14:36:32 +00:00
/* Parse comma separated list */
char * vals [ MAX_VALS ] ;
size_t j ;
args . channel_parse = ast_strdup ( i - > value ) ;
if ( ! args . channel_parse ) {
ast_ari_response_alloc_failed ( response ) ;
goto fin ;
}
ARI: WebSocket event cleanup
Stasis events (which get distributed over the ARI WebSocket) are created
by subscribing to the channel_all_cached and bridge_all_cached topics,
filtering out events for channels/bridges currently subscribed to.
There are two issues with that. First was a race condition, where
messages in-flight to the master subscribe-to-all-things topic would get
sent out, even though the events happened before the channel was put
into Stasis. Secondly, as the number of channels and bridges grow in the
system, the work spent filtering messages becomes excessive.
Since r395954, individual channels and bridges have caching topics, and
can be subscribed to individually. This patch takes advantage, so that
channels and bridges are subscribed to on demand, instead of filtering
the global topics.
The one case where filtering is still required is handling BridgeMerge
messages, which are published directly to the bridge_all topic.
Other than the change to how subscriptions work, this patch mostly just
moves code around. Most of the work generating JSON objects from
messages was moved to .to_json handlers on the message types. The
callback functions handling app subscriptions were moved from res_stasis
(b/c they were global to the model) to stasis/app.c (b/c they are local
to the app now).
(closes issue ASTERISK-21969)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2754/
........
Merged revisions 397816 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397820 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-08-27 19:19:36 +00:00
if ( strlen ( args . channel_parse ) = = 0 ) {
/* ast_app_separate_args can't handle "" */
args . channel_count = 1 ;
vals [ 0 ] = args . channel_parse ;
} else {
args . channel_count = ast_app_separate_args (
args . channel_parse , ' , ' , vals ,
ARRAY_LEN ( vals ) ) ;
}
2013-08-02 14:36:32 +00:00
if ( args . channel_count = = 0 ) {
ast_ari_response_alloc_failed ( response ) ;
goto fin ;
}
if ( args . channel_count > = MAX_VALS ) {
ast_ari_response_error ( response , 400 ,
" Bad Request " ,
" Too many values for channel " ) ;
goto fin ;
}
args . channel = ast_malloc ( sizeof ( * args . channel ) * args . channel_count ) ;
if ( ! args . channel ) {
ast_ari_response_alloc_failed ( response ) ;
goto fin ;
}
for ( j = 0 ; j < args . channel_count ; + + j ) {
args . channel [ j ] = ( vals [ j ] ) ;
}
2013-04-22 14:58:53 +00:00
} else
2013-08-05 16:59:13 +00:00
if ( strcmp ( i - > name , " role " ) = = 0 ) {
args . role = ( i - > value ) ;
} else
2017-10-06 21:48:48 -04:00
if ( strcmp ( i - > name , " absorbDTMF " ) = = 0 ) {
args . absorb_dtmf = ast_true ( i - > value ) ;
} else
if ( strcmp ( i - > name , " mute " ) = = 0 ) {
args . mute = ast_true ( i - > value ) ;
} else
2019-11-22 15:32:42 +01:00
if ( strcmp ( i - > name , " inhibitConnectedLineUpdates " ) = = 0 ) {
args . inhibit_connected_line_updates = ast_true ( i - > value ) ;
} else
2013-04-22 14:58:53 +00:00
{ }
}
for ( i = path_vars ; i ; i = i - > next ) {
if ( strcmp ( i - > name , " bridgeId " ) = = 0 ) {
args . bridge_id = ( i - > value ) ;
} else
{ }
}
2014-01-21 14:27:21 +00:00
if ( ast_ari_bridges_add_channel_parse_body ( body , & args ) ) {
ast_ari_response_alloc_failed ( response ) ;
goto fin ;
2013-11-27 15:48:39 +00:00
}
2013-11-07 21:10:31 +00:00
ast_ari_bridges_add_channel ( headers , & args , response ) ;
Update events to use Swagger 1.3 subtyping, and related aftermath
This patch started with the simple idea of changing the /events data
model to be more sane. The original model would send out events like:
{ "stasis_start": { "args": [], "channel": { ... } } }
The event discriminator was the field name instead of being a value in
the object, due to limitations in how Swagger 1.1 could model objects.
While technically sufficient in communicating event information, it was
really difficult to deal with in terms of client side JSON handling.
This patch takes advantage of a proposed extension[1] to Swagger which
allows type variance through the use of a discriminator field. This had
a domino effect that made this a surprisingly large patch.
[1]: https://groups.google.com/d/msg/wordnik-api/EC3rGajE0os/ey_5dBI_jWcJ
In changing the models, I also had to change the swagger_model.py
processor so it can handle the type discriminator and subtyping. I took
that a big step forward, and using that information to generate an
ari_model module, which can validate a JSON object against the Swagger
model.
The REST and WebSocket generators were changed to take advantage of the
validators. If compiled with AST_DEVMODE enabled, JSON objects that
don't match their corresponding models will not be sent out. For REST
API calls, a 500 Internal Server response is sent. For WebSockets, the
invalid JSON message is replaced with an error message.
Since this took over about half of the job of the existing JSON
generators, and the .to_json virtual function on messages took over the
other half, I reluctantly removed the generators.
The validators turned up all sorts of errors and inconsistencies in our
data models, and the code. These were cleaned up, with checks in the
code generator avoid some of the consistency problems in the future.
* The model for a channel snapshot was trimmed down to match the
information sent via AMI. Many of the field being sent were not
useful in the general case.
* The model for a bridge snapshot was updated to be more consistent
with the other ARI models.
Another impact of introducing subtyping was that the swagger-codegen
documentation generator was insufficient (at least until it catches up
with Swagger 1.2). I wanted it to be easier to generate docs for the API
anyways, so I ported the wiki pages to use the Asterisk Swagger
generator. In the process, I was able to clean up many of the model
links, which would occasionally give inconsistent results on the wiki. I
also added error responses to the wiki docs, making the wiki
documentation more complete.
Finally, since Stasis-HTTP will now be named Asterisk REST Interface
(ARI), any new functions and files I created carry the ari_ prefix. I
changed a few stasis_http references to ari where it was non-intrusive
and made sense.
(closes issue ASTERISK-21885)
Review: https://reviewboard.asterisk.org/r/2639/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393529 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-07-03 16:32:41 +00:00
# if defined(AST_DEVMODE)
code = response - > response_code ;
switch ( code ) {
2013-07-23 14:57:03 +00:00
case 0 : /* Implementation is still a stub, or the code wasn't set */
is_valid = response - > message = = NULL ;
break ;
case 500 : /* Internal Server Error */
case 501 : /* Not Implemented */
2013-08-23 17:19:02 +00:00
case 400 : /* Channel not found */
Update events to use Swagger 1.3 subtyping, and related aftermath
This patch started with the simple idea of changing the /events data
model to be more sane. The original model would send out events like:
{ "stasis_start": { "args": [], "channel": { ... } } }
The event discriminator was the field name instead of being a value in
the object, due to limitations in how Swagger 1.1 could model objects.
While technically sufficient in communicating event information, it was
really difficult to deal with in terms of client side JSON handling.
This patch takes advantage of a proposed extension[1] to Swagger which
allows type variance through the use of a discriminator field. This had
a domino effect that made this a surprisingly large patch.
[1]: https://groups.google.com/d/msg/wordnik-api/EC3rGajE0os/ey_5dBI_jWcJ
In changing the models, I also had to change the swagger_model.py
processor so it can handle the type discriminator and subtyping. I took
that a big step forward, and using that information to generate an
ari_model module, which can validate a JSON object against the Swagger
model.
The REST and WebSocket generators were changed to take advantage of the
validators. If compiled with AST_DEVMODE enabled, JSON objects that
don't match their corresponding models will not be sent out. For REST
API calls, a 500 Internal Server response is sent. For WebSockets, the
invalid JSON message is replaced with an error message.
Since this took over about half of the job of the existing JSON
generators, and the .to_json virtual function on messages took over the
other half, I reluctantly removed the generators.
The validators turned up all sorts of errors and inconsistencies in our
data models, and the code. These were cleaned up, with checks in the
code generator avoid some of the consistency problems in the future.
* The model for a channel snapshot was trimmed down to match the
information sent via AMI. Many of the field being sent were not
useful in the general case.
* The model for a bridge snapshot was updated to be more consistent
with the other ARI models.
Another impact of introducing subtyping was that the swagger-codegen
documentation generator was insufficient (at least until it catches up
with Swagger 1.2). I wanted it to be easier to generate docs for the API
anyways, so I ported the wiki pages to use the Asterisk Swagger
generator. In the process, I was able to clean up many of the model
links, which would occasionally give inconsistent results on the wiki. I
also added error responses to the wiki docs, making the wiki
documentation more complete.
Finally, since Stasis-HTTP will now be named Asterisk REST Interface
(ARI), any new functions and files I created carry the ari_ prefix. I
changed a few stasis_http references to ari where it was non-intrusive
and made sense.
(closes issue ASTERISK-21885)
Review: https://reviewboard.asterisk.org/r/2639/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393529 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-07-03 16:32:41 +00:00
case 404 : /* Bridge not found */
2013-12-13 16:38:57 +00:00
case 409 : /* Bridge not in Stasis application; Channel currently recording */
2013-08-23 17:19:02 +00:00
case 422 : /* Channel not in Stasis application */
Update events to use Swagger 1.3 subtyping, and related aftermath
This patch started with the simple idea of changing the /events data
model to be more sane. The original model would send out events like:
{ "stasis_start": { "args": [], "channel": { ... } } }
The event discriminator was the field name instead of being a value in
the object, due to limitations in how Swagger 1.1 could model objects.
While technically sufficient in communicating event information, it was
really difficult to deal with in terms of client side JSON handling.
This patch takes advantage of a proposed extension[1] to Swagger which
allows type variance through the use of a discriminator field. This had
a domino effect that made this a surprisingly large patch.
[1]: https://groups.google.com/d/msg/wordnik-api/EC3rGajE0os/ey_5dBI_jWcJ
In changing the models, I also had to change the swagger_model.py
processor so it can handle the type discriminator and subtyping. I took
that a big step forward, and using that information to generate an
ari_model module, which can validate a JSON object against the Swagger
model.
The REST and WebSocket generators were changed to take advantage of the
validators. If compiled with AST_DEVMODE enabled, JSON objects that
don't match their corresponding models will not be sent out. For REST
API calls, a 500 Internal Server response is sent. For WebSockets, the
invalid JSON message is replaced with an error message.
Since this took over about half of the job of the existing JSON
generators, and the .to_json virtual function on messages took over the
other half, I reluctantly removed the generators.
The validators turned up all sorts of errors and inconsistencies in our
data models, and the code. These were cleaned up, with checks in the
code generator avoid some of the consistency problems in the future.
* The model for a channel snapshot was trimmed down to match the
information sent via AMI. Many of the field being sent were not
useful in the general case.
* The model for a bridge snapshot was updated to be more consistent
with the other ARI models.
Another impact of introducing subtyping was that the swagger-codegen
documentation generator was insufficient (at least until it catches up
with Swagger 1.2). I wanted it to be easier to generate docs for the API
anyways, so I ported the wiki pages to use the Asterisk Swagger
generator. In the process, I was able to clean up many of the model
links, which would occasionally give inconsistent results on the wiki. I
also added error responses to the wiki docs, making the wiki
documentation more complete.
Finally, since Stasis-HTTP will now be named Asterisk REST Interface
(ARI), any new functions and files I created carry the ari_ prefix. I
changed a few stasis_http references to ari where it was non-intrusive
and made sense.
(closes issue ASTERISK-21885)
Review: https://reviewboard.asterisk.org/r/2639/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393529 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-07-03 16:32:41 +00:00
is_valid = 1 ;
break ;
default :
if ( 200 < = code & & code < = 299 ) {
2013-07-27 23:11:02 +00:00
is_valid = ast_ari_validate_void (
Update events to use Swagger 1.3 subtyping, and related aftermath
This patch started with the simple idea of changing the /events data
model to be more sane. The original model would send out events like:
{ "stasis_start": { "args": [], "channel": { ... } } }
The event discriminator was the field name instead of being a value in
the object, due to limitations in how Swagger 1.1 could model objects.
While technically sufficient in communicating event information, it was
really difficult to deal with in terms of client side JSON handling.
This patch takes advantage of a proposed extension[1] to Swagger which
allows type variance through the use of a discriminator field. This had
a domino effect that made this a surprisingly large patch.
[1]: https://groups.google.com/d/msg/wordnik-api/EC3rGajE0os/ey_5dBI_jWcJ
In changing the models, I also had to change the swagger_model.py
processor so it can handle the type discriminator and subtyping. I took
that a big step forward, and using that information to generate an
ari_model module, which can validate a JSON object against the Swagger
model.
The REST and WebSocket generators were changed to take advantage of the
validators. If compiled with AST_DEVMODE enabled, JSON objects that
don't match their corresponding models will not be sent out. For REST
API calls, a 500 Internal Server response is sent. For WebSockets, the
invalid JSON message is replaced with an error message.
Since this took over about half of the job of the existing JSON
generators, and the .to_json virtual function on messages took over the
other half, I reluctantly removed the generators.
The validators turned up all sorts of errors and inconsistencies in our
data models, and the code. These were cleaned up, with checks in the
code generator avoid some of the consistency problems in the future.
* The model for a channel snapshot was trimmed down to match the
information sent via AMI. Many of the field being sent were not
useful in the general case.
* The model for a bridge snapshot was updated to be more consistent
with the other ARI models.
Another impact of introducing subtyping was that the swagger-codegen
documentation generator was insufficient (at least until it catches up
with Swagger 1.2). I wanted it to be easier to generate docs for the API
anyways, so I ported the wiki pages to use the Asterisk Swagger
generator. In the process, I was able to clean up many of the model
links, which would occasionally give inconsistent results on the wiki. I
also added error responses to the wiki docs, making the wiki
documentation more complete.
Finally, since Stasis-HTTP will now be named Asterisk REST Interface
(ARI), any new functions and files I created carry the ari_ prefix. I
changed a few stasis_http references to ari where it was non-intrusive
and made sense.
(closes issue ASTERISK-21885)
Review: https://reviewboard.asterisk.org/r/2639/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393529 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-07-03 16:32:41 +00:00
response - > message ) ;
} else {
ast_log ( LOG_ERROR , " Invalid error response %d for /bridges/{bridgeId}/addChannel \n " , code ) ;
is_valid = 0 ;
}
}
if ( ! is_valid ) {
ast_log ( LOG_ERROR , " Response validation failed for /bridges/{bridgeId}/addChannel \n " ) ;
2013-07-27 23:11:02 +00:00
ast_ari_response_error ( response , 500 ,
Update events to use Swagger 1.3 subtyping, and related aftermath
This patch started with the simple idea of changing the /events data
model to be more sane. The original model would send out events like:
{ "stasis_start": { "args": [], "channel": { ... } } }
The event discriminator was the field name instead of being a value in
the object, due to limitations in how Swagger 1.1 could model objects.
While technically sufficient in communicating event information, it was
really difficult to deal with in terms of client side JSON handling.
This patch takes advantage of a proposed extension[1] to Swagger which
allows type variance through the use of a discriminator field. This had
a domino effect that made this a surprisingly large patch.
[1]: https://groups.google.com/d/msg/wordnik-api/EC3rGajE0os/ey_5dBI_jWcJ
In changing the models, I also had to change the swagger_model.py
processor so it can handle the type discriminator and subtyping. I took
that a big step forward, and using that information to generate an
ari_model module, which can validate a JSON object against the Swagger
model.
The REST and WebSocket generators were changed to take advantage of the
validators. If compiled with AST_DEVMODE enabled, JSON objects that
don't match their corresponding models will not be sent out. For REST
API calls, a 500 Internal Server response is sent. For WebSockets, the
invalid JSON message is replaced with an error message.
Since this took over about half of the job of the existing JSON
generators, and the .to_json virtual function on messages took over the
other half, I reluctantly removed the generators.
The validators turned up all sorts of errors and inconsistencies in our
data models, and the code. These were cleaned up, with checks in the
code generator avoid some of the consistency problems in the future.
* The model for a channel snapshot was trimmed down to match the
information sent via AMI. Many of the field being sent were not
useful in the general case.
* The model for a bridge snapshot was updated to be more consistent
with the other ARI models.
Another impact of introducing subtyping was that the swagger-codegen
documentation generator was insufficient (at least until it catches up
with Swagger 1.2). I wanted it to be easier to generate docs for the API
anyways, so I ported the wiki pages to use the Asterisk Swagger
generator. In the process, I was able to clean up many of the model
links, which would occasionally give inconsistent results on the wiki. I
also added error responses to the wiki docs, making the wiki
documentation more complete.
Finally, since Stasis-HTTP will now be named Asterisk REST Interface
(ARI), any new functions and files I created carry the ari_ prefix. I
changed a few stasis_http references to ari where it was non-intrusive
and made sense.
(closes issue ASTERISK-21885)
Review: https://reviewboard.asterisk.org/r/2639/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393529 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-07-03 16:32:41 +00:00
" Internal Server Error " , " Response validation failed " ) ;
}
# endif /* AST_DEVMODE */
2013-08-02 14:36:32 +00:00
fin : __attribute__ ( ( unused ) )
ast_free ( args . channel_parse ) ;
ast_free ( args . channel ) ;
return ;
2013-04-22 14:58:53 +00:00
}
2014-01-21 14:27:21 +00:00
int ast_ari_bridges_remove_channel_parse_body (
struct ast_json * body ,
struct ast_ari_bridges_remove_channel_args * args )
{
struct ast_json * field ;
/* Parse query parameters out of it */
field = ast_json_object_get ( body , " channel " ) ;
if ( field ) {
/* If they were silly enough to both pass in a query param and a
* JSON body , free up the query value .
*/
ast_free ( args - > channel ) ;
if ( ast_json_typeof ( field ) = = AST_JSON_ARRAY ) {
/* Multiple param passed as array */
size_t i ;
args - > channel_count = ast_json_array_size ( field ) ;
args - > channel = ast_malloc ( sizeof ( * args - > channel ) * args - > channel_count ) ;
if ( ! args - > channel ) {
return - 1 ;
}
for ( i = 0 ; i < args - > channel_count ; + + i ) {
args - > channel [ i ] = ast_json_string_get ( ast_json_array_get ( field , i ) ) ;
}
} else {
/* Multiple param passed as single value */
args - > channel_count = 1 ;
args - > channel = ast_malloc ( sizeof ( * args - > channel ) * args - > channel_count ) ;
if ( ! args - > channel ) {
return - 1 ;
}
args - > channel [ 0 ] = ast_json_string_get ( field ) ;
}
}
return 0 ;
}
2013-04-22 14:58:53 +00:00
/*!
* \ brief Parameter parsing callback for / bridges / { bridgeId } / removeChannel .
2021-11-17 13:18:32 +01:00
* \ param ser TCP / TLS session object
2013-04-22 14:58:53 +00:00
* \ param get_params GET parameters in the HTTP request .
* \ param path_vars Path variables extracted from the request .
* \ param headers HTTP headers .
2021-11-17 13:18:32 +01:00
* \ param body
2013-04-22 14:58:53 +00:00
* \ param [ out ] response Response to the HTTP request .
*/
2013-11-07 21:10:31 +00:00
static void ast_ari_bridges_remove_channel_cb (
2013-11-27 15:48:39 +00:00
struct ast_tcptls_session_instance * ser ,
Update events to use Swagger 1.3 subtyping, and related aftermath
This patch started with the simple idea of changing the /events data
model to be more sane. The original model would send out events like:
{ "stasis_start": { "args": [], "channel": { ... } } }
The event discriminator was the field name instead of being a value in
the object, due to limitations in how Swagger 1.1 could model objects.
While technically sufficient in communicating event information, it was
really difficult to deal with in terms of client side JSON handling.
This patch takes advantage of a proposed extension[1] to Swagger which
allows type variance through the use of a discriminator field. This had
a domino effect that made this a surprisingly large patch.
[1]: https://groups.google.com/d/msg/wordnik-api/EC3rGajE0os/ey_5dBI_jWcJ
In changing the models, I also had to change the swagger_model.py
processor so it can handle the type discriminator and subtyping. I took
that a big step forward, and using that information to generate an
ari_model module, which can validate a JSON object against the Swagger
model.
The REST and WebSocket generators were changed to take advantage of the
validators. If compiled with AST_DEVMODE enabled, JSON objects that
don't match their corresponding models will not be sent out. For REST
API calls, a 500 Internal Server response is sent. For WebSockets, the
invalid JSON message is replaced with an error message.
Since this took over about half of the job of the existing JSON
generators, and the .to_json virtual function on messages took over the
other half, I reluctantly removed the generators.
The validators turned up all sorts of errors and inconsistencies in our
data models, and the code. These were cleaned up, with checks in the
code generator avoid some of the consistency problems in the future.
* The model for a channel snapshot was trimmed down to match the
information sent via AMI. Many of the field being sent were not
useful in the general case.
* The model for a bridge snapshot was updated to be more consistent
with the other ARI models.
Another impact of introducing subtyping was that the swagger-codegen
documentation generator was insufficient (at least until it catches up
with Swagger 1.2). I wanted it to be easier to generate docs for the API
anyways, so I ported the wiki pages to use the Asterisk Swagger
generator. In the process, I was able to clean up many of the model
links, which would occasionally give inconsistent results on the wiki. I
also added error responses to the wiki docs, making the wiki
documentation more complete.
Finally, since Stasis-HTTP will now be named Asterisk REST Interface
(ARI), any new functions and files I created carry the ari_ prefix. I
changed a few stasis_http references to ari where it was non-intrusive
and made sense.
(closes issue ASTERISK-21885)
Review: https://reviewboard.asterisk.org/r/2639/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393529 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-07-03 16:32:41 +00:00
struct ast_variable * get_params , struct ast_variable * path_vars ,
2017-01-19 08:05:36 -07:00
struct ast_variable * headers , struct ast_json * body , struct ast_ari_response * response )
2013-04-22 14:58:53 +00:00
{
2013-11-07 21:10:31 +00:00
struct ast_ari_bridges_remove_channel_args args = { } ;
2013-08-02 14:36:32 +00:00
struct ast_variable * i ;
Update events to use Swagger 1.3 subtyping, and related aftermath
This patch started with the simple idea of changing the /events data
model to be more sane. The original model would send out events like:
{ "stasis_start": { "args": [], "channel": { ... } } }
The event discriminator was the field name instead of being a value in
the object, due to limitations in how Swagger 1.1 could model objects.
While technically sufficient in communicating event information, it was
really difficult to deal with in terms of client side JSON handling.
This patch takes advantage of a proposed extension[1] to Swagger which
allows type variance through the use of a discriminator field. This had
a domino effect that made this a surprisingly large patch.
[1]: https://groups.google.com/d/msg/wordnik-api/EC3rGajE0os/ey_5dBI_jWcJ
In changing the models, I also had to change the swagger_model.py
processor so it can handle the type discriminator and subtyping. I took
that a big step forward, and using that information to generate an
ari_model module, which can validate a JSON object against the Swagger
model.
The REST and WebSocket generators were changed to take advantage of the
validators. If compiled with AST_DEVMODE enabled, JSON objects that
don't match their corresponding models will not be sent out. For REST
API calls, a 500 Internal Server response is sent. For WebSockets, the
invalid JSON message is replaced with an error message.
Since this took over about half of the job of the existing JSON
generators, and the .to_json virtual function on messages took over the
other half, I reluctantly removed the generators.
The validators turned up all sorts of errors and inconsistencies in our
data models, and the code. These were cleaned up, with checks in the
code generator avoid some of the consistency problems in the future.
* The model for a channel snapshot was trimmed down to match the
information sent via AMI. Many of the field being sent were not
useful in the general case.
* The model for a bridge snapshot was updated to be more consistent
with the other ARI models.
Another impact of introducing subtyping was that the swagger-codegen
documentation generator was insufficient (at least until it catches up
with Swagger 1.2). I wanted it to be easier to generate docs for the API
anyways, so I ported the wiki pages to use the Asterisk Swagger
generator. In the process, I was able to clean up many of the model
links, which would occasionally give inconsistent results on the wiki. I
also added error responses to the wiki docs, making the wiki
documentation more complete.
Finally, since Stasis-HTTP will now be named Asterisk REST Interface
(ARI), any new functions and files I created carry the ari_ prefix. I
changed a few stasis_http references to ari where it was non-intrusive
and made sense.
(closes issue ASTERISK-21885)
Review: https://reviewboard.asterisk.org/r/2639/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393529 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-07-03 16:32:41 +00:00
# if defined(AST_DEVMODE)
int is_valid ;
int code ;
# endif /* AST_DEVMODE */
2013-04-22 14:58:53 +00:00
for ( i = get_params ; i ; i = i - > next ) {
if ( strcmp ( i - > name , " channel " ) = = 0 ) {
2013-08-02 14:36:32 +00:00
/* Parse comma separated list */
char * vals [ MAX_VALS ] ;
size_t j ;
args . channel_parse = ast_strdup ( i - > value ) ;
if ( ! args . channel_parse ) {
ast_ari_response_alloc_failed ( response ) ;
goto fin ;
}
ARI: WebSocket event cleanup
Stasis events (which get distributed over the ARI WebSocket) are created
by subscribing to the channel_all_cached and bridge_all_cached topics,
filtering out events for channels/bridges currently subscribed to.
There are two issues with that. First was a race condition, where
messages in-flight to the master subscribe-to-all-things topic would get
sent out, even though the events happened before the channel was put
into Stasis. Secondly, as the number of channels and bridges grow in the
system, the work spent filtering messages becomes excessive.
Since r395954, individual channels and bridges have caching topics, and
can be subscribed to individually. This patch takes advantage, so that
channels and bridges are subscribed to on demand, instead of filtering
the global topics.
The one case where filtering is still required is handling BridgeMerge
messages, which are published directly to the bridge_all topic.
Other than the change to how subscriptions work, this patch mostly just
moves code around. Most of the work generating JSON objects from
messages was moved to .to_json handlers on the message types. The
callback functions handling app subscriptions were moved from res_stasis
(b/c they were global to the model) to stasis/app.c (b/c they are local
to the app now).
(closes issue ASTERISK-21969)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2754/
........
Merged revisions 397816 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397820 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-08-27 19:19:36 +00:00
if ( strlen ( args . channel_parse ) = = 0 ) {
/* ast_app_separate_args can't handle "" */
args . channel_count = 1 ;
vals [ 0 ] = args . channel_parse ;
} else {
args . channel_count = ast_app_separate_args (
args . channel_parse , ' , ' , vals ,
ARRAY_LEN ( vals ) ) ;
}
2013-08-02 14:36:32 +00:00
if ( args . channel_count = = 0 ) {
ast_ari_response_alloc_failed ( response ) ;
goto fin ;
}
if ( args . channel_count > = MAX_VALS ) {
ast_ari_response_error ( response , 400 ,
" Bad Request " ,
" Too many values for channel " ) ;
goto fin ;
}
args . channel = ast_malloc ( sizeof ( * args . channel ) * args . channel_count ) ;
if ( ! args . channel ) {
ast_ari_response_alloc_failed ( response ) ;
goto fin ;
}
for ( j = 0 ; j < args . channel_count ; + + j ) {
args . channel [ j ] = ( vals [ j ] ) ;
}
2013-04-22 14:58:53 +00:00
} else
{ }
}
for ( i = path_vars ; i ; i = i - > next ) {
if ( strcmp ( i - > name , " bridgeId " ) = = 0 ) {
args . bridge_id = ( i - > value ) ;
} else
{ }
}
2014-01-21 14:27:21 +00:00
if ( ast_ari_bridges_remove_channel_parse_body ( body , & args ) ) {
ast_ari_response_alloc_failed ( response ) ;
goto fin ;
2013-11-27 15:48:39 +00:00
}
2013-11-07 21:10:31 +00:00
ast_ari_bridges_remove_channel ( headers , & args , response ) ;
Update events to use Swagger 1.3 subtyping, and related aftermath
This patch started with the simple idea of changing the /events data
model to be more sane. The original model would send out events like:
{ "stasis_start": { "args": [], "channel": { ... } } }
The event discriminator was the field name instead of being a value in
the object, due to limitations in how Swagger 1.1 could model objects.
While technically sufficient in communicating event information, it was
really difficult to deal with in terms of client side JSON handling.
This patch takes advantage of a proposed extension[1] to Swagger which
allows type variance through the use of a discriminator field. This had
a domino effect that made this a surprisingly large patch.
[1]: https://groups.google.com/d/msg/wordnik-api/EC3rGajE0os/ey_5dBI_jWcJ
In changing the models, I also had to change the swagger_model.py
processor so it can handle the type discriminator and subtyping. I took
that a big step forward, and using that information to generate an
ari_model module, which can validate a JSON object against the Swagger
model.
The REST and WebSocket generators were changed to take advantage of the
validators. If compiled with AST_DEVMODE enabled, JSON objects that
don't match their corresponding models will not be sent out. For REST
API calls, a 500 Internal Server response is sent. For WebSockets, the
invalid JSON message is replaced with an error message.
Since this took over about half of the job of the existing JSON
generators, and the .to_json virtual function on messages took over the
other half, I reluctantly removed the generators.
The validators turned up all sorts of errors and inconsistencies in our
data models, and the code. These were cleaned up, with checks in the
code generator avoid some of the consistency problems in the future.
* The model for a channel snapshot was trimmed down to match the
information sent via AMI. Many of the field being sent were not
useful in the general case.
* The model for a bridge snapshot was updated to be more consistent
with the other ARI models.
Another impact of introducing subtyping was that the swagger-codegen
documentation generator was insufficient (at least until it catches up
with Swagger 1.2). I wanted it to be easier to generate docs for the API
anyways, so I ported the wiki pages to use the Asterisk Swagger
generator. In the process, I was able to clean up many of the model
links, which would occasionally give inconsistent results on the wiki. I
also added error responses to the wiki docs, making the wiki
documentation more complete.
Finally, since Stasis-HTTP will now be named Asterisk REST Interface
(ARI), any new functions and files I created carry the ari_ prefix. I
changed a few stasis_http references to ari where it was non-intrusive
and made sense.
(closes issue ASTERISK-21885)
Review: https://reviewboard.asterisk.org/r/2639/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393529 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-07-03 16:32:41 +00:00
# if defined(AST_DEVMODE)
code = response - > response_code ;
switch ( code ) {
2013-07-23 14:57:03 +00:00
case 0 : /* Implementation is still a stub, or the code wasn't set */
is_valid = response - > message = = NULL ;
break ;
case 500 : /* Internal Server Error */
case 501 : /* Not Implemented */
2013-08-23 17:19:02 +00:00
case 400 : /* Channel not found */
case 404 : /* Bridge not found */
case 409 : /* Bridge not in Stasis application */
case 422 : /* Channel not in this bridge */
Update events to use Swagger 1.3 subtyping, and related aftermath
This patch started with the simple idea of changing the /events data
model to be more sane. The original model would send out events like:
{ "stasis_start": { "args": [], "channel": { ... } } }
The event discriminator was the field name instead of being a value in
the object, due to limitations in how Swagger 1.1 could model objects.
While technically sufficient in communicating event information, it was
really difficult to deal with in terms of client side JSON handling.
This patch takes advantage of a proposed extension[1] to Swagger which
allows type variance through the use of a discriminator field. This had
a domino effect that made this a surprisingly large patch.
[1]: https://groups.google.com/d/msg/wordnik-api/EC3rGajE0os/ey_5dBI_jWcJ
In changing the models, I also had to change the swagger_model.py
processor so it can handle the type discriminator and subtyping. I took
that a big step forward, and using that information to generate an
ari_model module, which can validate a JSON object against the Swagger
model.
The REST and WebSocket generators were changed to take advantage of the
validators. If compiled with AST_DEVMODE enabled, JSON objects that
don't match their corresponding models will not be sent out. For REST
API calls, a 500 Internal Server response is sent. For WebSockets, the
invalid JSON message is replaced with an error message.
Since this took over about half of the job of the existing JSON
generators, and the .to_json virtual function on messages took over the
other half, I reluctantly removed the generators.
The validators turned up all sorts of errors and inconsistencies in our
data models, and the code. These were cleaned up, with checks in the
code generator avoid some of the consistency problems in the future.
* The model for a channel snapshot was trimmed down to match the
information sent via AMI. Many of the field being sent were not
useful in the general case.
* The model for a bridge snapshot was updated to be more consistent
with the other ARI models.
Another impact of introducing subtyping was that the swagger-codegen
documentation generator was insufficient (at least until it catches up
with Swagger 1.2). I wanted it to be easier to generate docs for the API
anyways, so I ported the wiki pages to use the Asterisk Swagger
generator. In the process, I was able to clean up many of the model
links, which would occasionally give inconsistent results on the wiki. I
also added error responses to the wiki docs, making the wiki
documentation more complete.
Finally, since Stasis-HTTP will now be named Asterisk REST Interface
(ARI), any new functions and files I created carry the ari_ prefix. I
changed a few stasis_http references to ari where it was non-intrusive
and made sense.
(closes issue ASTERISK-21885)
Review: https://reviewboard.asterisk.org/r/2639/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393529 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-07-03 16:32:41 +00:00
is_valid = 1 ;
break ;
default :
if ( 200 < = code & & code < = 299 ) {
2013-07-27 23:11:02 +00:00
is_valid = ast_ari_validate_void (
Update events to use Swagger 1.3 subtyping, and related aftermath
This patch started with the simple idea of changing the /events data
model to be more sane. The original model would send out events like:
{ "stasis_start": { "args": [], "channel": { ... } } }
The event discriminator was the field name instead of being a value in
the object, due to limitations in how Swagger 1.1 could model objects.
While technically sufficient in communicating event information, it was
really difficult to deal with in terms of client side JSON handling.
This patch takes advantage of a proposed extension[1] to Swagger which
allows type variance through the use of a discriminator field. This had
a domino effect that made this a surprisingly large patch.
[1]: https://groups.google.com/d/msg/wordnik-api/EC3rGajE0os/ey_5dBI_jWcJ
In changing the models, I also had to change the swagger_model.py
processor so it can handle the type discriminator and subtyping. I took
that a big step forward, and using that information to generate an
ari_model module, which can validate a JSON object against the Swagger
model.
The REST and WebSocket generators were changed to take advantage of the
validators. If compiled with AST_DEVMODE enabled, JSON objects that
don't match their corresponding models will not be sent out. For REST
API calls, a 500 Internal Server response is sent. For WebSockets, the
invalid JSON message is replaced with an error message.
Since this took over about half of the job of the existing JSON
generators, and the .to_json virtual function on messages took over the
other half, I reluctantly removed the generators.
The validators turned up all sorts of errors and inconsistencies in our
data models, and the code. These were cleaned up, with checks in the
code generator avoid some of the consistency problems in the future.
* The model for a channel snapshot was trimmed down to match the
information sent via AMI. Many of the field being sent were not
useful in the general case.
* The model for a bridge snapshot was updated to be more consistent
with the other ARI models.
Another impact of introducing subtyping was that the swagger-codegen
documentation generator was insufficient (at least until it catches up
with Swagger 1.2). I wanted it to be easier to generate docs for the API
anyways, so I ported the wiki pages to use the Asterisk Swagger
generator. In the process, I was able to clean up many of the model
links, which would occasionally give inconsistent results on the wiki. I
also added error responses to the wiki docs, making the wiki
documentation more complete.
Finally, since Stasis-HTTP will now be named Asterisk REST Interface
(ARI), any new functions and files I created carry the ari_ prefix. I
changed a few stasis_http references to ari where it was non-intrusive
and made sense.
(closes issue ASTERISK-21885)
Review: https://reviewboard.asterisk.org/r/2639/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393529 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-07-03 16:32:41 +00:00
response - > message ) ;
} else {
ast_log ( LOG_ERROR , " Invalid error response %d for /bridges/{bridgeId}/removeChannel \n " , code ) ;
is_valid = 0 ;
}
}
if ( ! is_valid ) {
ast_log ( LOG_ERROR , " Response validation failed for /bridges/{bridgeId}/removeChannel \n " ) ;
2013-07-27 23:11:02 +00:00
ast_ari_response_error ( response , 500 ,
Update events to use Swagger 1.3 subtyping, and related aftermath
This patch started with the simple idea of changing the /events data
model to be more sane. The original model would send out events like:
{ "stasis_start": { "args": [], "channel": { ... } } }
The event discriminator was the field name instead of being a value in
the object, due to limitations in how Swagger 1.1 could model objects.
While technically sufficient in communicating event information, it was
really difficult to deal with in terms of client side JSON handling.
This patch takes advantage of a proposed extension[1] to Swagger which
allows type variance through the use of a discriminator field. This had
a domino effect that made this a surprisingly large patch.
[1]: https://groups.google.com/d/msg/wordnik-api/EC3rGajE0os/ey_5dBI_jWcJ
In changing the models, I also had to change the swagger_model.py
processor so it can handle the type discriminator and subtyping. I took
that a big step forward, and using that information to generate an
ari_model module, which can validate a JSON object against the Swagger
model.
The REST and WebSocket generators were changed to take advantage of the
validators. If compiled with AST_DEVMODE enabled, JSON objects that
don't match their corresponding models will not be sent out. For REST
API calls, a 500 Internal Server response is sent. For WebSockets, the
invalid JSON message is replaced with an error message.
Since this took over about half of the job of the existing JSON
generators, and the .to_json virtual function on messages took over the
other half, I reluctantly removed the generators.
The validators turned up all sorts of errors and inconsistencies in our
data models, and the code. These were cleaned up, with checks in the
code generator avoid some of the consistency problems in the future.
* The model for a channel snapshot was trimmed down to match the
information sent via AMI. Many of the field being sent were not
useful in the general case.
* The model for a bridge snapshot was updated to be more consistent
with the other ARI models.
Another impact of introducing subtyping was that the swagger-codegen
documentation generator was insufficient (at least until it catches up
with Swagger 1.2). I wanted it to be easier to generate docs for the API
anyways, so I ported the wiki pages to use the Asterisk Swagger
generator. In the process, I was able to clean up many of the model
links, which would occasionally give inconsistent results on the wiki. I
also added error responses to the wiki docs, making the wiki
documentation more complete.
Finally, since Stasis-HTTP will now be named Asterisk REST Interface
(ARI), any new functions and files I created carry the ari_ prefix. I
changed a few stasis_http references to ari where it was non-intrusive
and made sense.
(closes issue ASTERISK-21885)
Review: https://reviewboard.asterisk.org/r/2639/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393529 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-07-03 16:32:41 +00:00
" Internal Server Error " , " Response validation failed " ) ;
}
# endif /* AST_DEVMODE */
2013-08-02 14:36:32 +00:00
fin : __attribute__ ( ( unused ) )
ast_free ( args . channel_parse ) ;
ast_free ( args . channel ) ;
return ;
2013-04-22 14:58:53 +00:00
}
2016-11-08 10:11:41 -06:00
/*!
* \ brief Parameter parsing callback for / bridges / { bridgeId } / videoSource / { channelId } .
2021-11-17 13:18:32 +01:00
* \ param ser TCP / TLS session object
2016-11-08 10:11:41 -06:00
* \ param get_params GET parameters in the HTTP request .
* \ param path_vars Path variables extracted from the request .
* \ param headers HTTP headers .
2021-11-17 13:18:32 +01:00
* \ param body
2016-11-08 10:11:41 -06:00
* \ param [ out ] response Response to the HTTP request .
*/
static void ast_ari_bridges_set_video_source_cb (
struct ast_tcptls_session_instance * ser ,
struct ast_variable * get_params , struct ast_variable * path_vars ,
2017-01-19 08:05:36 -07:00
struct ast_variable * headers , struct ast_json * body , struct ast_ari_response * response )
2016-11-08 10:11:41 -06:00
{
struct ast_ari_bridges_set_video_source_args args = { } ;
struct ast_variable * i ;
# if defined(AST_DEVMODE)
int is_valid ;
int code ;
# endif /* AST_DEVMODE */
for ( i = path_vars ; i ; i = i - > next ) {
if ( strcmp ( i - > name , " bridgeId " ) = = 0 ) {
args . bridge_id = ( i - > value ) ;
} else
if ( strcmp ( i - > name , " channelId " ) = = 0 ) {
args . channel_id = ( i - > value ) ;
} else
{ }
}
ast_ari_bridges_set_video_source ( headers , & args , response ) ;
# if defined(AST_DEVMODE)
code = response - > response_code ;
switch ( code ) {
case 0 : /* Implementation is still a stub, or the code wasn't set */
is_valid = response - > message = = NULL ;
break ;
case 500 : /* Internal Server Error */
case 501 : /* Not Implemented */
case 404 : /* Bridge or Channel not found */
case 409 : /* Channel not in Stasis application */
case 422 : /* Channel not in this Bridge */
is_valid = 1 ;
break ;
default :
if ( 200 < = code & & code < = 299 ) {
is_valid = ast_ari_validate_void (
response - > message ) ;
} else {
ast_log ( LOG_ERROR , " Invalid error response %d for /bridges/{bridgeId}/videoSource/{channelId} \n " , code ) ;
is_valid = 0 ;
}
}
if ( ! is_valid ) {
ast_log ( LOG_ERROR , " Response validation failed for /bridges/{bridgeId}/videoSource/{channelId} \n " ) ;
ast_ari_response_error ( response , 500 ,
" Internal Server Error " , " Response validation failed " ) ;
}
# endif /* AST_DEVMODE */
fin : __attribute__ ( ( unused ) )
return ;
}
/*!
* \ brief Parameter parsing callback for / bridges / { bridgeId } / videoSource .
2021-11-17 13:18:32 +01:00
* \ param ser TCP / TLS session object
2016-11-08 10:11:41 -06:00
* \ param get_params GET parameters in the HTTP request .
* \ param path_vars Path variables extracted from the request .
* \ param headers HTTP headers .
2021-11-17 13:18:32 +01:00
* \ param body
2016-11-08 10:11:41 -06:00
* \ param [ out ] response Response to the HTTP request .
*/
static void ast_ari_bridges_clear_video_source_cb (
struct ast_tcptls_session_instance * ser ,
struct ast_variable * get_params , struct ast_variable * path_vars ,
2017-01-19 08:05:36 -07:00
struct ast_variable * headers , struct ast_json * body , struct ast_ari_response * response )
2016-11-08 10:11:41 -06:00
{
struct ast_ari_bridges_clear_video_source_args args = { } ;
struct ast_variable * i ;
# if defined(AST_DEVMODE)
int is_valid ;
int code ;
# endif /* AST_DEVMODE */
for ( i = path_vars ; i ; i = i - > next ) {
if ( strcmp ( i - > name , " bridgeId " ) = = 0 ) {
args . bridge_id = ( i - > value ) ;
} else
{ }
}
ast_ari_bridges_clear_video_source ( headers , & args , response ) ;
# if defined(AST_DEVMODE)
code = response - > response_code ;
switch ( code ) {
case 0 : /* Implementation is still a stub, or the code wasn't set */
is_valid = response - > message = = NULL ;
break ;
case 500 : /* Internal Server Error */
case 501 : /* Not Implemented */
case 404 : /* Bridge not found */
is_valid = 1 ;
break ;
default :
if ( 200 < = code & & code < = 299 ) {
is_valid = ast_ari_validate_void (
response - > message ) ;
} else {
ast_log ( LOG_ERROR , " Invalid error response %d for /bridges/{bridgeId}/videoSource \n " , code ) ;
is_valid = 0 ;
}
}
if ( ! is_valid ) {
ast_log ( LOG_ERROR , " Response validation failed for /bridges/{bridgeId}/videoSource \n " ) ;
ast_ari_response_error ( response , 500 ,
" Internal Server Error " , " Response validation failed " ) ;
}
# endif /* AST_DEVMODE */
fin : __attribute__ ( ( unused ) )
return ;
}
2014-01-21 14:27:21 +00:00
int ast_ari_bridges_start_moh_parse_body (
struct ast_json * body ,
struct ast_ari_bridges_start_moh_args * args )
{
struct ast_json * field ;
/* Parse query parameters out of it */
field = ast_json_object_get ( body , " mohClass " ) ;
if ( field ) {
args - > moh_class = ast_json_string_get ( field ) ;
}
return 0 ;
}
2013-08-23 00:26:19 +00:00
/*!
2013-10-16 00:12:36 +00:00
* \ brief Parameter parsing callback for / bridges / { bridgeId } / moh .
2021-11-17 13:18:32 +01:00
* \ param ser TCP / TLS session object
2013-08-23 00:26:19 +00:00
* \ param get_params GET parameters in the HTTP request .
* \ param path_vars Path variables extracted from the request .
* \ param headers HTTP headers .
2021-11-17 13:18:32 +01:00
* \ param body
2013-08-23 00:26:19 +00:00
* \ param [ out ] response Response to the HTTP request .
*/
2013-11-07 21:10:31 +00:00
static void ast_ari_bridges_start_moh_cb (
2013-11-27 15:48:39 +00:00
struct ast_tcptls_session_instance * ser ,
2013-08-23 00:26:19 +00:00
struct ast_variable * get_params , struct ast_variable * path_vars ,
2017-01-19 08:05:36 -07:00
struct ast_variable * headers , struct ast_json * body , struct ast_ari_response * response )
2013-08-23 00:26:19 +00:00
{
2013-11-07 21:10:31 +00:00
struct ast_ari_bridges_start_moh_args args = { } ;
2013-08-23 00:26:19 +00:00
struct ast_variable * i ;
# if defined(AST_DEVMODE)
int is_valid ;
int code ;
# endif /* AST_DEVMODE */
for ( i = get_params ; i ; i = i - > next ) {
if ( strcmp ( i - > name , " mohClass " ) = = 0 ) {
args . moh_class = ( i - > value ) ;
} else
{ }
}
for ( i = path_vars ; i ; i = i - > next ) {
if ( strcmp ( i - > name , " bridgeId " ) = = 0 ) {
args . bridge_id = ( i - > value ) ;
} else
{ }
}
2014-01-21 14:27:21 +00:00
if ( ast_ari_bridges_start_moh_parse_body ( body , & args ) ) {
ast_ari_response_alloc_failed ( response ) ;
goto fin ;
2013-11-27 15:48:39 +00:00
}
2013-11-07 21:10:31 +00:00
ast_ari_bridges_start_moh ( headers , & args , response ) ;
2013-08-23 00:26:19 +00:00
# if defined(AST_DEVMODE)
code = response - > response_code ;
switch ( code ) {
case 0 : /* Implementation is still a stub, or the code wasn't set */
is_valid = response - > message = = NULL ;
break ;
case 500 : /* Internal Server Error */
case 501 : /* Not Implemented */
case 404 : /* Bridge not found */
case 409 : /* Bridge not in Stasis application */
is_valid = 1 ;
break ;
default :
if ( 200 < = code & & code < = 299 ) {
is_valid = ast_ari_validate_void (
response - > message ) ;
} else {
2013-10-16 00:12:36 +00:00
ast_log ( LOG_ERROR , " Invalid error response %d for /bridges/{bridgeId}/moh \n " , code ) ;
2013-08-23 00:26:19 +00:00
is_valid = 0 ;
}
}
if ( ! is_valid ) {
2013-10-16 00:12:36 +00:00
ast_log ( LOG_ERROR , " Response validation failed for /bridges/{bridgeId}/moh \n " ) ;
2013-08-23 00:26:19 +00:00
ast_ari_response_error ( response , 500 ,
" Internal Server Error " , " Response validation failed " ) ;
}
# endif /* AST_DEVMODE */
fin : __attribute__ ( ( unused ) )
return ;
}
/*!
2013-10-16 00:12:36 +00:00
* \ brief Parameter parsing callback for / bridges / { bridgeId } / moh .
2021-11-17 13:18:32 +01:00
* \ param ser TCP / TLS session object
2013-08-23 00:26:19 +00:00
* \ param get_params GET parameters in the HTTP request .
* \ param path_vars Path variables extracted from the request .
* \ param headers HTTP headers .
2021-11-17 13:18:32 +01:00
* \ param body
2013-08-23 00:26:19 +00:00
* \ param [ out ] response Response to the HTTP request .
*/
2013-11-07 21:10:31 +00:00
static void ast_ari_bridges_stop_moh_cb (
2013-11-27 15:48:39 +00:00
struct ast_tcptls_session_instance * ser ,
2013-08-23 00:26:19 +00:00
struct ast_variable * get_params , struct ast_variable * path_vars ,
2017-01-19 08:05:36 -07:00
struct ast_variable * headers , struct ast_json * body , struct ast_ari_response * response )
2013-08-23 00:26:19 +00:00
{
2013-11-07 21:10:31 +00:00
struct ast_ari_bridges_stop_moh_args args = { } ;
2013-08-23 00:26:19 +00:00
struct ast_variable * i ;
# if defined(AST_DEVMODE)
int is_valid ;
int code ;
# endif /* AST_DEVMODE */
for ( i = path_vars ; i ; i = i - > next ) {
if ( strcmp ( i - > name , " bridgeId " ) = = 0 ) {
args . bridge_id = ( i - > value ) ;
} else
{ }
}
2013-11-07 21:10:31 +00:00
ast_ari_bridges_stop_moh ( headers , & args , response ) ;
2013-08-23 00:26:19 +00:00
# if defined(AST_DEVMODE)
code = response - > response_code ;
switch ( code ) {
case 0 : /* Implementation is still a stub, or the code wasn't set */
is_valid = response - > message = = NULL ;
break ;
case 500 : /* Internal Server Error */
case 501 : /* Not Implemented */
case 404 : /* Bridge not found */
case 409 : /* Bridge not in Stasis application */
is_valid = 1 ;
break ;
default :
if ( 200 < = code & & code < = 299 ) {
is_valid = ast_ari_validate_void (
response - > message ) ;
} else {
2013-10-16 00:12:36 +00:00
ast_log ( LOG_ERROR , " Invalid error response %d for /bridges/{bridgeId}/moh \n " , code ) ;
2013-08-23 00:26:19 +00:00
is_valid = 0 ;
}
}
if ( ! is_valid ) {
2013-10-16 00:12:36 +00:00
ast_log ( LOG_ERROR , " Response validation failed for /bridges/{bridgeId}/moh \n " ) ;
2013-08-23 00:26:19 +00:00
ast_ari_response_error ( response , 500 ,
" Internal Server Error " , " Response validation failed " ) ;
}
# endif /* AST_DEVMODE */
fin : __attribute__ ( ( unused ) )
return ;
}
2014-01-21 14:27:21 +00:00
int ast_ari_bridges_play_parse_body (
struct ast_json * body ,
struct ast_ari_bridges_play_args * args )
{
struct ast_json * field ;
/* Parse query parameters out of it */
field = ast_json_object_get ( body , " media " ) ;
if ( field ) {
ARI: Add the ability to play multiple media URIs in a single operation
Many ARI applications will want to play multiple media files in a row to
a resource. The most common use case is when building long-ish IVR prompts
made up of multiple, smaller sound files. Today, that requires building a
small state machine, listening for each PlaybackFinished event, and triggering
the next sound file to play. While not especially challenging, it is tedious
work. Since requiring developers to write tedious code to do normal activities
stinks, this patch adds the ability to play back a list of media files to a
resource.
Each of the 'play' operations on supported resources (channels and bridges)
now accepts a comma delineated list of media URIs to play. A single Playback
resource is created as a handle to the entire list. The operation of playing
a list is identical to playing a single media URI, save that a new event,
PlaybackContinuing, is raised instead of a PlaybackFinished for each non-final
media URI. When the entire list is finished being played, a PlaybackFinished
event is raised.
In order to help inform applications where they are in the list playback, the
Playback resource now includes a new, optional attribute, 'next_media_uri',
that contains the next URI in the list to be played.
It's important to note the following:
- If an offset is provided to the 'play' operations, it only applies to the
first media URI, as it would be weird to skip n seconds forward in every
media resource.
- Operations that control the position of the media only affect the current
media being played. For example, once a media resource in the list
completes, a 'reverse' operation on a subsequent media resource will not
start a previously completed media resource at the appropiate offset.
- This patch does not add any new operations to control the list. Hopefully,
user feedback and/or future patches would add that if people want it.
ASTERISK-26022 #close
Change-Id: Ie1ea5356573447b8f51f2e7964915ea01792f16f
2016-04-18 18:17:08 -05:00
/* If they were silly enough to both pass in a query param and a
* JSON body , free up the query value .
*/
ast_free ( args - > media ) ;
if ( ast_json_typeof ( field ) = = AST_JSON_ARRAY ) {
/* Multiple param passed as array */
size_t i ;
args - > media_count = ast_json_array_size ( field ) ;
args - > media = ast_malloc ( sizeof ( * args - > media ) * args - > media_count ) ;
if ( ! args - > media ) {
return - 1 ;
}
for ( i = 0 ; i < args - > media_count ; + + i ) {
args - > media [ i ] = ast_json_string_get ( ast_json_array_get ( field , i ) ) ;
}
} else {
/* Multiple param passed as single value */
args - > media_count = 1 ;
args - > media = ast_malloc ( sizeof ( * args - > media ) * args - > media_count ) ;
if ( ! args - > media ) {
return - 1 ;
}
args - > media [ 0 ] = ast_json_string_get ( field ) ;
}
2014-01-21 14:27:21 +00:00
}
2025-09-25 11:48:01 -06:00
field = ast_json_object_get ( body , " announcer_format " ) ;
if ( field ) {
args - > announcer_format = ast_json_string_get ( field ) ;
}
2014-01-21 14:27:21 +00:00
field = ast_json_object_get ( body , " lang " ) ;
if ( field ) {
args - > lang = ast_json_string_get ( field ) ;
}
field = ast_json_object_get ( body , " offsetms " ) ;
if ( field ) {
args - > offsetms = ast_json_integer_get ( field ) ;
}
field = ast_json_object_get ( body , " skipms " ) ;
if ( field ) {
args - > skipms = ast_json_integer_get ( field ) ;
}
2014-04-18 20:09:24 +00:00
field = ast_json_object_get ( body , " playbackId " ) ;
if ( field ) {
args - > playback_id = ast_json_string_get ( field ) ;
}
2014-01-21 14:27:21 +00:00
return 0 ;
}
2013-07-19 19:35:21 +00:00
/*!
* \ brief Parameter parsing callback for / bridges / { bridgeId } / play .
2021-11-17 13:18:32 +01:00
* \ param ser TCP / TLS session object
2013-07-19 19:35:21 +00:00
* \ param get_params GET parameters in the HTTP request .
* \ param path_vars Path variables extracted from the request .
* \ param headers HTTP headers .
2021-11-17 13:18:32 +01:00
* \ param body
2013-07-19 19:35:21 +00:00
* \ param [ out ] response Response to the HTTP request .
*/
2013-11-07 21:10:31 +00:00
static void ast_ari_bridges_play_cb (
2013-11-27 15:48:39 +00:00
struct ast_tcptls_session_instance * ser ,
2013-07-19 19:35:21 +00:00
struct ast_variable * get_params , struct ast_variable * path_vars ,
2017-01-19 08:05:36 -07:00
struct ast_variable * headers , struct ast_json * body , struct ast_ari_response * response )
2013-07-19 19:35:21 +00:00
{
2013-11-07 21:10:31 +00:00
struct ast_ari_bridges_play_args args = { } ;
2013-08-02 14:36:32 +00:00
struct ast_variable * i ;
2013-07-19 19:35:21 +00:00
# if defined(AST_DEVMODE)
int is_valid ;
int code ;
# endif /* AST_DEVMODE */
for ( i = get_params ; i ; i = i - > next ) {
if ( strcmp ( i - > name , " media " ) = = 0 ) {
ARI: Add the ability to play multiple media URIs in a single operation
Many ARI applications will want to play multiple media files in a row to
a resource. The most common use case is when building long-ish IVR prompts
made up of multiple, smaller sound files. Today, that requires building a
small state machine, listening for each PlaybackFinished event, and triggering
the next sound file to play. While not especially challenging, it is tedious
work. Since requiring developers to write tedious code to do normal activities
stinks, this patch adds the ability to play back a list of media files to a
resource.
Each of the 'play' operations on supported resources (channels and bridges)
now accepts a comma delineated list of media URIs to play. A single Playback
resource is created as a handle to the entire list. The operation of playing
a list is identical to playing a single media URI, save that a new event,
PlaybackContinuing, is raised instead of a PlaybackFinished for each non-final
media URI. When the entire list is finished being played, a PlaybackFinished
event is raised.
In order to help inform applications where they are in the list playback, the
Playback resource now includes a new, optional attribute, 'next_media_uri',
that contains the next URI in the list to be played.
It's important to note the following:
- If an offset is provided to the 'play' operations, it only applies to the
first media URI, as it would be weird to skip n seconds forward in every
media resource.
- Operations that control the position of the media only affect the current
media being played. For example, once a media resource in the list
completes, a 'reverse' operation on a subsequent media resource will not
start a previously completed media resource at the appropiate offset.
- This patch does not add any new operations to control the list. Hopefully,
user feedback and/or future patches would add that if people want it.
ASTERISK-26022 #close
Change-Id: Ie1ea5356573447b8f51f2e7964915ea01792f16f
2016-04-18 18:17:08 -05:00
/* Parse comma separated list */
char * vals [ MAX_VALS ] ;
size_t j ;
args . media_parse = ast_strdup ( i - > value ) ;
if ( ! args . media_parse ) {
ast_ari_response_alloc_failed ( response ) ;
goto fin ;
}
if ( strlen ( args . media_parse ) = = 0 ) {
/* ast_app_separate_args can't handle "" */
args . media_count = 1 ;
vals [ 0 ] = args . media_parse ;
} else {
args . media_count = ast_app_separate_args (
args . media_parse , ' , ' , vals ,
ARRAY_LEN ( vals ) ) ;
}
if ( args . media_count = = 0 ) {
ast_ari_response_alloc_failed ( response ) ;
goto fin ;
}
if ( args . media_count > = MAX_VALS ) {
ast_ari_response_error ( response , 400 ,
" Bad Request " ,
" Too many values for media " ) ;
goto fin ;
}
args . media = ast_malloc ( sizeof ( * args . media ) * args . media_count ) ;
if ( ! args . media ) {
ast_ari_response_alloc_failed ( response ) ;
goto fin ;
}
for ( j = 0 ; j < args . media_count ; + + j ) {
args . media [ j ] = ( vals [ j ] ) ;
}
2013-07-19 19:35:21 +00:00
} else
2025-09-25 11:48:01 -06:00
if ( strcmp ( i - > name , " announcer_format " ) = = 0 ) {
args . announcer_format = ( i - > value ) ;
} else
2013-07-19 19:35:21 +00:00
if ( strcmp ( i - > name , " lang " ) = = 0 ) {
args . lang = ( i - > value ) ;
} else
if ( strcmp ( i - > name , " offsetms " ) = = 0 ) {
args . offsetms = atoi ( i - > value ) ;
} else
if ( strcmp ( i - > name , " skipms " ) = = 0 ) {
args . skipms = atoi ( i - > value ) ;
} else
2014-04-18 20:09:24 +00:00
if ( strcmp ( i - > name , " playbackId " ) = = 0 ) {
args . playback_id = ( i - > value ) ;
} else
2013-07-19 19:35:21 +00:00
{ }
}
for ( i = path_vars ; i ; i = i - > next ) {
if ( strcmp ( i - > name , " bridgeId " ) = = 0 ) {
args . bridge_id = ( i - > value ) ;
} else
{ }
}
2014-01-21 14:27:21 +00:00
if ( ast_ari_bridges_play_parse_body ( body , & args ) ) {
ast_ari_response_alloc_failed ( response ) ;
goto fin ;
2013-11-27 15:48:39 +00:00
}
2013-11-07 21:10:31 +00:00
ast_ari_bridges_play ( headers , & args , response ) ;
2013-07-19 19:35:21 +00:00
# if defined(AST_DEVMODE)
code = response - > response_code ;
switch ( code ) {
2013-07-23 14:57:03 +00:00
case 0 : /* Implementation is still a stub, or the code wasn't set */
is_valid = response - > message = = NULL ;
break ;
case 500 : /* Internal Server Error */
case 501 : /* Not Implemented */
2013-07-19 19:35:21 +00:00
case 404 : /* Bridge not found */
case 409 : /* Bridge not in a Stasis application */
2025-09-25 11:48:01 -06:00
case 422 : /* The format specified is unknown on this system */
2013-07-19 19:35:21 +00:00
is_valid = 1 ;
break ;
default :
if ( 200 < = code & & code < = 299 ) {
2013-07-27 23:11:02 +00:00
is_valid = ast_ari_validate_playback (
2013-07-19 19:35:21 +00:00
response - > message ) ;
} else {
ast_log ( LOG_ERROR , " Invalid error response %d for /bridges/{bridgeId}/play \n " , code ) ;
is_valid = 0 ;
}
}
if ( ! is_valid ) {
ast_log ( LOG_ERROR , " Response validation failed for /bridges/{bridgeId}/play \n " ) ;
2013-07-27 23:11:02 +00:00
ast_ari_response_error ( response , 500 ,
2013-07-19 19:35:21 +00:00
" Internal Server Error " , " Response validation failed " ) ;
}
# endif /* AST_DEVMODE */
2013-08-02 14:36:32 +00:00
2014-04-18 20:09:24 +00:00
fin : __attribute__ ( ( unused ) )
ARI: Add the ability to play multiple media URIs in a single operation
Many ARI applications will want to play multiple media files in a row to
a resource. The most common use case is when building long-ish IVR prompts
made up of multiple, smaller sound files. Today, that requires building a
small state machine, listening for each PlaybackFinished event, and triggering
the next sound file to play. While not especially challenging, it is tedious
work. Since requiring developers to write tedious code to do normal activities
stinks, this patch adds the ability to play back a list of media files to a
resource.
Each of the 'play' operations on supported resources (channels and bridges)
now accepts a comma delineated list of media URIs to play. A single Playback
resource is created as a handle to the entire list. The operation of playing
a list is identical to playing a single media URI, save that a new event,
PlaybackContinuing, is raised instead of a PlaybackFinished for each non-final
media URI. When the entire list is finished being played, a PlaybackFinished
event is raised.
In order to help inform applications where they are in the list playback, the
Playback resource now includes a new, optional attribute, 'next_media_uri',
that contains the next URI in the list to be played.
It's important to note the following:
- If an offset is provided to the 'play' operations, it only applies to the
first media URI, as it would be weird to skip n seconds forward in every
media resource.
- Operations that control the position of the media only affect the current
media being played. For example, once a media resource in the list
completes, a 'reverse' operation on a subsequent media resource will not
start a previously completed media resource at the appropiate offset.
- This patch does not add any new operations to control the list. Hopefully,
user feedback and/or future patches would add that if people want it.
ASTERISK-26022 #close
Change-Id: Ie1ea5356573447b8f51f2e7964915ea01792f16f
2016-04-18 18:17:08 -05:00
ast_free ( args . media_parse ) ;
ast_free ( args . media ) ;
2014-04-18 20:09:24 +00:00
return ;
}
int ast_ari_bridges_play_with_id_parse_body (
struct ast_json * body ,
struct ast_ari_bridges_play_with_id_args * args )
{
struct ast_json * field ;
/* Parse query parameters out of it */
field = ast_json_object_get ( body , " media " ) ;
if ( field ) {
ARI: Add the ability to play multiple media URIs in a single operation
Many ARI applications will want to play multiple media files in a row to
a resource. The most common use case is when building long-ish IVR prompts
made up of multiple, smaller sound files. Today, that requires building a
small state machine, listening for each PlaybackFinished event, and triggering
the next sound file to play. While not especially challenging, it is tedious
work. Since requiring developers to write tedious code to do normal activities
stinks, this patch adds the ability to play back a list of media files to a
resource.
Each of the 'play' operations on supported resources (channels and bridges)
now accepts a comma delineated list of media URIs to play. A single Playback
resource is created as a handle to the entire list. The operation of playing
a list is identical to playing a single media URI, save that a new event,
PlaybackContinuing, is raised instead of a PlaybackFinished for each non-final
media URI. When the entire list is finished being played, a PlaybackFinished
event is raised.
In order to help inform applications where they are in the list playback, the
Playback resource now includes a new, optional attribute, 'next_media_uri',
that contains the next URI in the list to be played.
It's important to note the following:
- If an offset is provided to the 'play' operations, it only applies to the
first media URI, as it would be weird to skip n seconds forward in every
media resource.
- Operations that control the position of the media only affect the current
media being played. For example, once a media resource in the list
completes, a 'reverse' operation on a subsequent media resource will not
start a previously completed media resource at the appropiate offset.
- This patch does not add any new operations to control the list. Hopefully,
user feedback and/or future patches would add that if people want it.
ASTERISK-26022 #close
Change-Id: Ie1ea5356573447b8f51f2e7964915ea01792f16f
2016-04-18 18:17:08 -05:00
/* If they were silly enough to both pass in a query param and a
* JSON body , free up the query value .
*/
ast_free ( args - > media ) ;
if ( ast_json_typeof ( field ) = = AST_JSON_ARRAY ) {
/* Multiple param passed as array */
size_t i ;
args - > media_count = ast_json_array_size ( field ) ;
args - > media = ast_malloc ( sizeof ( * args - > media ) * args - > media_count ) ;
if ( ! args - > media ) {
return - 1 ;
}
for ( i = 0 ; i < args - > media_count ; + + i ) {
args - > media [ i ] = ast_json_string_get ( ast_json_array_get ( field , i ) ) ;
}
} else {
/* Multiple param passed as single value */
args - > media_count = 1 ;
args - > media = ast_malloc ( sizeof ( * args - > media ) * args - > media_count ) ;
if ( ! args - > media ) {
return - 1 ;
}
args - > media [ 0 ] = ast_json_string_get ( field ) ;
}
2014-04-18 20:09:24 +00:00
}
2025-09-25 11:48:01 -06:00
field = ast_json_object_get ( body , " announcer_format " ) ;
if ( field ) {
args - > announcer_format = ast_json_string_get ( field ) ;
}
2014-04-18 20:09:24 +00:00
field = ast_json_object_get ( body , " lang " ) ;
if ( field ) {
args - > lang = ast_json_string_get ( field ) ;
}
field = ast_json_object_get ( body , " offsetms " ) ;
if ( field ) {
args - > offsetms = ast_json_integer_get ( field ) ;
}
field = ast_json_object_get ( body , " skipms " ) ;
if ( field ) {
args - > skipms = ast_json_integer_get ( field ) ;
}
return 0 ;
}
/*!
* \ brief Parameter parsing callback for / bridges / { bridgeId } / play / { playbackId } .
2021-11-17 13:18:32 +01:00
* \ param ser TCP / TLS session object
2014-04-18 20:09:24 +00:00
* \ param get_params GET parameters in the HTTP request .
* \ param path_vars Path variables extracted from the request .
* \ param headers HTTP headers .
2021-11-17 13:18:32 +01:00
* \ param body
2014-04-18 20:09:24 +00:00
* \ param [ out ] response Response to the HTTP request .
*/
static void ast_ari_bridges_play_with_id_cb (
struct ast_tcptls_session_instance * ser ,
struct ast_variable * get_params , struct ast_variable * path_vars ,
2017-01-19 08:05:36 -07:00
struct ast_variable * headers , struct ast_json * body , struct ast_ari_response * response )
2014-04-18 20:09:24 +00:00
{
struct ast_ari_bridges_play_with_id_args args = { } ;
struct ast_variable * i ;
# if defined(AST_DEVMODE)
int is_valid ;
int code ;
# endif /* AST_DEVMODE */
for ( i = get_params ; i ; i = i - > next ) {
if ( strcmp ( i - > name , " media " ) = = 0 ) {
ARI: Add the ability to play multiple media URIs in a single operation
Many ARI applications will want to play multiple media files in a row to
a resource. The most common use case is when building long-ish IVR prompts
made up of multiple, smaller sound files. Today, that requires building a
small state machine, listening for each PlaybackFinished event, and triggering
the next sound file to play. While not especially challenging, it is tedious
work. Since requiring developers to write tedious code to do normal activities
stinks, this patch adds the ability to play back a list of media files to a
resource.
Each of the 'play' operations on supported resources (channels and bridges)
now accepts a comma delineated list of media URIs to play. A single Playback
resource is created as a handle to the entire list. The operation of playing
a list is identical to playing a single media URI, save that a new event,
PlaybackContinuing, is raised instead of a PlaybackFinished for each non-final
media URI. When the entire list is finished being played, a PlaybackFinished
event is raised.
In order to help inform applications where they are in the list playback, the
Playback resource now includes a new, optional attribute, 'next_media_uri',
that contains the next URI in the list to be played.
It's important to note the following:
- If an offset is provided to the 'play' operations, it only applies to the
first media URI, as it would be weird to skip n seconds forward in every
media resource.
- Operations that control the position of the media only affect the current
media being played. For example, once a media resource in the list
completes, a 'reverse' operation on a subsequent media resource will not
start a previously completed media resource at the appropiate offset.
- This patch does not add any new operations to control the list. Hopefully,
user feedback and/or future patches would add that if people want it.
ASTERISK-26022 #close
Change-Id: Ie1ea5356573447b8f51f2e7964915ea01792f16f
2016-04-18 18:17:08 -05:00
/* Parse comma separated list */
char * vals [ MAX_VALS ] ;
size_t j ;
args . media_parse = ast_strdup ( i - > value ) ;
if ( ! args . media_parse ) {
ast_ari_response_alloc_failed ( response ) ;
goto fin ;
}
if ( strlen ( args . media_parse ) = = 0 ) {
/* ast_app_separate_args can't handle "" */
args . media_count = 1 ;
vals [ 0 ] = args . media_parse ;
} else {
args . media_count = ast_app_separate_args (
args . media_parse , ' , ' , vals ,
ARRAY_LEN ( vals ) ) ;
}
if ( args . media_count = = 0 ) {
ast_ari_response_alloc_failed ( response ) ;
goto fin ;
}
if ( args . media_count > = MAX_VALS ) {
ast_ari_response_error ( response , 400 ,
" Bad Request " ,
" Too many values for media " ) ;
goto fin ;
}
args . media = ast_malloc ( sizeof ( * args . media ) * args . media_count ) ;
if ( ! args . media ) {
ast_ari_response_alloc_failed ( response ) ;
goto fin ;
}
for ( j = 0 ; j < args . media_count ; + + j ) {
args . media [ j ] = ( vals [ j ] ) ;
}
2014-04-18 20:09:24 +00:00
} else
2025-09-25 11:48:01 -06:00
if ( strcmp ( i - > name , " announcer_format " ) = = 0 ) {
args . announcer_format = ( i - > value ) ;
} else
2014-04-18 20:09:24 +00:00
if ( strcmp ( i - > name , " lang " ) = = 0 ) {
args . lang = ( i - > value ) ;
} else
if ( strcmp ( i - > name , " offsetms " ) = = 0 ) {
args . offsetms = atoi ( i - > value ) ;
} else
if ( strcmp ( i - > name , " skipms " ) = = 0 ) {
args . skipms = atoi ( i - > value ) ;
} else
{ }
}
for ( i = path_vars ; i ; i = i - > next ) {
if ( strcmp ( i - > name , " bridgeId " ) = = 0 ) {
args . bridge_id = ( i - > value ) ;
} else
if ( strcmp ( i - > name , " playbackId " ) = = 0 ) {
args . playback_id = ( i - > value ) ;
} else
{ }
}
if ( ast_ari_bridges_play_with_id_parse_body ( body , & args ) ) {
ast_ari_response_alloc_failed ( response ) ;
goto fin ;
}
ast_ari_bridges_play_with_id ( headers , & args , response ) ;
# if defined(AST_DEVMODE)
code = response - > response_code ;
switch ( code ) {
case 0 : /* Implementation is still a stub, or the code wasn't set */
is_valid = response - > message = = NULL ;
break ;
case 500 : /* Internal Server Error */
case 501 : /* Not Implemented */
case 404 : /* Bridge not found */
case 409 : /* Bridge not in a Stasis application */
2025-09-25 11:48:01 -06:00
case 422 : /* The format specified is unknown on this system */
2014-04-18 20:09:24 +00:00
is_valid = 1 ;
break ;
default :
if ( 200 < = code & & code < = 299 ) {
is_valid = ast_ari_validate_playback (
response - > message ) ;
} else {
ast_log ( LOG_ERROR , " Invalid error response %d for /bridges/{bridgeId}/play/{playbackId} \n " , code ) ;
is_valid = 0 ;
}
}
if ( ! is_valid ) {
ast_log ( LOG_ERROR , " Response validation failed for /bridges/{bridgeId}/play/{playbackId} \n " ) ;
ast_ari_response_error ( response , 500 ,
" Internal Server Error " , " Response validation failed " ) ;
}
# endif /* AST_DEVMODE */
2013-08-02 14:36:32 +00:00
fin : __attribute__ ( ( unused ) )
ARI: Add the ability to play multiple media URIs in a single operation
Many ARI applications will want to play multiple media files in a row to
a resource. The most common use case is when building long-ish IVR prompts
made up of multiple, smaller sound files. Today, that requires building a
small state machine, listening for each PlaybackFinished event, and triggering
the next sound file to play. While not especially challenging, it is tedious
work. Since requiring developers to write tedious code to do normal activities
stinks, this patch adds the ability to play back a list of media files to a
resource.
Each of the 'play' operations on supported resources (channels and bridges)
now accepts a comma delineated list of media URIs to play. A single Playback
resource is created as a handle to the entire list. The operation of playing
a list is identical to playing a single media URI, save that a new event,
PlaybackContinuing, is raised instead of a PlaybackFinished for each non-final
media URI. When the entire list is finished being played, a PlaybackFinished
event is raised.
In order to help inform applications where they are in the list playback, the
Playback resource now includes a new, optional attribute, 'next_media_uri',
that contains the next URI in the list to be played.
It's important to note the following:
- If an offset is provided to the 'play' operations, it only applies to the
first media URI, as it would be weird to skip n seconds forward in every
media resource.
- Operations that control the position of the media only affect the current
media being played. For example, once a media resource in the list
completes, a 'reverse' operation on a subsequent media resource will not
start a previously completed media resource at the appropiate offset.
- This patch does not add any new operations to control the list. Hopefully,
user feedback and/or future patches would add that if people want it.
ASTERISK-26022 #close
Change-Id: Ie1ea5356573447b8f51f2e7964915ea01792f16f
2016-04-18 18:17:08 -05:00
ast_free ( args . media_parse ) ;
ast_free ( args . media ) ;
2013-08-02 14:36:32 +00:00
return ;
2013-07-19 19:35:21 +00:00
}
2014-01-21 14:27:21 +00:00
int ast_ari_bridges_record_parse_body (
struct ast_json * body ,
struct ast_ari_bridges_record_args * args )
{
struct ast_json * field ;
/* Parse query parameters out of it */
field = ast_json_object_get ( body , " name " ) ;
if ( field ) {
args - > name = ast_json_string_get ( field ) ;
}
field = ast_json_object_get ( body , " format " ) ;
if ( field ) {
args - > format = ast_json_string_get ( field ) ;
}
2025-09-25 11:48:01 -06:00
field = ast_json_object_get ( body , " recorder_format " ) ;
if ( field ) {
args - > recorder_format = ast_json_string_get ( field ) ;
}
2014-01-21 14:27:21 +00:00
field = ast_json_object_get ( body , " maxDurationSeconds " ) ;
if ( field ) {
args - > max_duration_seconds = ast_json_integer_get ( field ) ;
}
field = ast_json_object_get ( body , " maxSilenceSeconds " ) ;
if ( field ) {
args - > max_silence_seconds = ast_json_integer_get ( field ) ;
}
field = ast_json_object_get ( body , " ifExists " ) ;
if ( field ) {
args - > if_exists = ast_json_string_get ( field ) ;
}
field = ast_json_object_get ( body , " beep " ) ;
if ( field ) {
args - > beep = ast_json_is_true ( field ) ;
}
field = ast_json_object_get ( body , " terminateOn " ) ;
if ( field ) {
args - > terminate_on = ast_json_string_get ( field ) ;
}
return 0 ;
}
2013-04-22 14:58:53 +00:00
/*!
* \ brief Parameter parsing callback for / bridges / { bridgeId } / record .
2021-11-17 13:18:32 +01:00
* \ param ser TCP / TLS session object
2013-04-22 14:58:53 +00:00
* \ param get_params GET parameters in the HTTP request .
* \ param path_vars Path variables extracted from the request .
* \ param headers HTTP headers .
2021-11-17 13:18:32 +01:00
* \ param body
2013-04-22 14:58:53 +00:00
* \ param [ out ] response Response to the HTTP request .
*/
2013-11-07 21:10:31 +00:00
static void ast_ari_bridges_record_cb (
2013-11-27 15:48:39 +00:00
struct ast_tcptls_session_instance * ser ,
Update events to use Swagger 1.3 subtyping, and related aftermath
This patch started with the simple idea of changing the /events data
model to be more sane. The original model would send out events like:
{ "stasis_start": { "args": [], "channel": { ... } } }
The event discriminator was the field name instead of being a value in
the object, due to limitations in how Swagger 1.1 could model objects.
While technically sufficient in communicating event information, it was
really difficult to deal with in terms of client side JSON handling.
This patch takes advantage of a proposed extension[1] to Swagger which
allows type variance through the use of a discriminator field. This had
a domino effect that made this a surprisingly large patch.
[1]: https://groups.google.com/d/msg/wordnik-api/EC3rGajE0os/ey_5dBI_jWcJ
In changing the models, I also had to change the swagger_model.py
processor so it can handle the type discriminator and subtyping. I took
that a big step forward, and using that information to generate an
ari_model module, which can validate a JSON object against the Swagger
model.
The REST and WebSocket generators were changed to take advantage of the
validators. If compiled with AST_DEVMODE enabled, JSON objects that
don't match their corresponding models will not be sent out. For REST
API calls, a 500 Internal Server response is sent. For WebSockets, the
invalid JSON message is replaced with an error message.
Since this took over about half of the job of the existing JSON
generators, and the .to_json virtual function on messages took over the
other half, I reluctantly removed the generators.
The validators turned up all sorts of errors and inconsistencies in our
data models, and the code. These were cleaned up, with checks in the
code generator avoid some of the consistency problems in the future.
* The model for a channel snapshot was trimmed down to match the
information sent via AMI. Many of the field being sent were not
useful in the general case.
* The model for a bridge snapshot was updated to be more consistent
with the other ARI models.
Another impact of introducing subtyping was that the swagger-codegen
documentation generator was insufficient (at least until it catches up
with Swagger 1.2). I wanted it to be easier to generate docs for the API
anyways, so I ported the wiki pages to use the Asterisk Swagger
generator. In the process, I was able to clean up many of the model
links, which would occasionally give inconsistent results on the wiki. I
also added error responses to the wiki docs, making the wiki
documentation more complete.
Finally, since Stasis-HTTP will now be named Asterisk REST Interface
(ARI), any new functions and files I created carry the ari_ prefix. I
changed a few stasis_http references to ari where it was non-intrusive
and made sense.
(closes issue ASTERISK-21885)
Review: https://reviewboard.asterisk.org/r/2639/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393529 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-07-03 16:32:41 +00:00
struct ast_variable * get_params , struct ast_variable * path_vars ,
2017-01-19 08:05:36 -07:00
struct ast_variable * headers , struct ast_json * body , struct ast_ari_response * response )
2013-04-22 14:58:53 +00:00
{
2013-11-07 21:10:31 +00:00
struct ast_ari_bridges_record_args args = { } ;
2013-08-02 14:36:32 +00:00
struct ast_variable * i ;
Update events to use Swagger 1.3 subtyping, and related aftermath
This patch started with the simple idea of changing the /events data
model to be more sane. The original model would send out events like:
{ "stasis_start": { "args": [], "channel": { ... } } }
The event discriminator was the field name instead of being a value in
the object, due to limitations in how Swagger 1.1 could model objects.
While technically sufficient in communicating event information, it was
really difficult to deal with in terms of client side JSON handling.
This patch takes advantage of a proposed extension[1] to Swagger which
allows type variance through the use of a discriminator field. This had
a domino effect that made this a surprisingly large patch.
[1]: https://groups.google.com/d/msg/wordnik-api/EC3rGajE0os/ey_5dBI_jWcJ
In changing the models, I also had to change the swagger_model.py
processor so it can handle the type discriminator and subtyping. I took
that a big step forward, and using that information to generate an
ari_model module, which can validate a JSON object against the Swagger
model.
The REST and WebSocket generators were changed to take advantage of the
validators. If compiled with AST_DEVMODE enabled, JSON objects that
don't match their corresponding models will not be sent out. For REST
API calls, a 500 Internal Server response is sent. For WebSockets, the
invalid JSON message is replaced with an error message.
Since this took over about half of the job of the existing JSON
generators, and the .to_json virtual function on messages took over the
other half, I reluctantly removed the generators.
The validators turned up all sorts of errors and inconsistencies in our
data models, and the code. These were cleaned up, with checks in the
code generator avoid some of the consistency problems in the future.
* The model for a channel snapshot was trimmed down to match the
information sent via AMI. Many of the field being sent were not
useful in the general case.
* The model for a bridge snapshot was updated to be more consistent
with the other ARI models.
Another impact of introducing subtyping was that the swagger-codegen
documentation generator was insufficient (at least until it catches up
with Swagger 1.2). I wanted it to be easier to generate docs for the API
anyways, so I ported the wiki pages to use the Asterisk Swagger
generator. In the process, I was able to clean up many of the model
links, which would occasionally give inconsistent results on the wiki. I
also added error responses to the wiki docs, making the wiki
documentation more complete.
Finally, since Stasis-HTTP will now be named Asterisk REST Interface
(ARI), any new functions and files I created carry the ari_ prefix. I
changed a few stasis_http references to ari where it was non-intrusive
and made sense.
(closes issue ASTERISK-21885)
Review: https://reviewboard.asterisk.org/r/2639/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393529 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-07-03 16:32:41 +00:00
# if defined(AST_DEVMODE)
int is_valid ;
int code ;
# endif /* AST_DEVMODE */
2013-04-22 14:58:53 +00:00
for ( i = get_params ; i ; i = i - > next ) {
if ( strcmp ( i - > name , " name " ) = = 0 ) {
args . name = ( i - > value ) ;
} else
2013-07-19 19:35:21 +00:00
if ( strcmp ( i - > name , " format " ) = = 0 ) {
args . format = ( i - > value ) ;
} else
2025-09-25 11:48:01 -06:00
if ( strcmp ( i - > name , " recorder_format " ) = = 0 ) {
args . recorder_format = ( i - > value ) ;
} else
2013-04-22 14:58:53 +00:00
if ( strcmp ( i - > name , " maxDurationSeconds " ) = = 0 ) {
args . max_duration_seconds = atoi ( i - > value ) ;
} else
if ( strcmp ( i - > name , " maxSilenceSeconds " ) = = 0 ) {
args . max_silence_seconds = atoi ( i - > value ) ;
} else
2013-07-19 19:35:21 +00:00
if ( strcmp ( i - > name , " ifExists " ) = = 0 ) {
args . if_exists = ( i - > value ) ;
2013-04-22 14:58:53 +00:00
} else
if ( strcmp ( i - > name , " beep " ) = = 0 ) {
2013-07-03 17:58:45 +00:00
args . beep = ast_true ( i - > value ) ;
2013-04-22 14:58:53 +00:00
} else
if ( strcmp ( i - > name , " terminateOn " ) = = 0 ) {
args . terminate_on = ( i - > value ) ;
} else
{ }
}
for ( i = path_vars ; i ; i = i - > next ) {
if ( strcmp ( i - > name , " bridgeId " ) = = 0 ) {
args . bridge_id = ( i - > value ) ;
} else
{ }
}
2014-01-21 14:27:21 +00:00
if ( ast_ari_bridges_record_parse_body ( body , & args ) ) {
ast_ari_response_alloc_failed ( response ) ;
goto fin ;
2013-11-27 15:48:39 +00:00
}
2013-11-07 21:10:31 +00:00
ast_ari_bridges_record ( headers , & args , response ) ;
Update events to use Swagger 1.3 subtyping, and related aftermath
This patch started with the simple idea of changing the /events data
model to be more sane. The original model would send out events like:
{ "stasis_start": { "args": [], "channel": { ... } } }
The event discriminator was the field name instead of being a value in
the object, due to limitations in how Swagger 1.1 could model objects.
While technically sufficient in communicating event information, it was
really difficult to deal with in terms of client side JSON handling.
This patch takes advantage of a proposed extension[1] to Swagger which
allows type variance through the use of a discriminator field. This had
a domino effect that made this a surprisingly large patch.
[1]: https://groups.google.com/d/msg/wordnik-api/EC3rGajE0os/ey_5dBI_jWcJ
In changing the models, I also had to change the swagger_model.py
processor so it can handle the type discriminator and subtyping. I took
that a big step forward, and using that information to generate an
ari_model module, which can validate a JSON object against the Swagger
model.
The REST and WebSocket generators were changed to take advantage of the
validators. If compiled with AST_DEVMODE enabled, JSON objects that
don't match their corresponding models will not be sent out. For REST
API calls, a 500 Internal Server response is sent. For WebSockets, the
invalid JSON message is replaced with an error message.
Since this took over about half of the job of the existing JSON
generators, and the .to_json virtual function on messages took over the
other half, I reluctantly removed the generators.
The validators turned up all sorts of errors and inconsistencies in our
data models, and the code. These were cleaned up, with checks in the
code generator avoid some of the consistency problems in the future.
* The model for a channel snapshot was trimmed down to match the
information sent via AMI. Many of the field being sent were not
useful in the general case.
* The model for a bridge snapshot was updated to be more consistent
with the other ARI models.
Another impact of introducing subtyping was that the swagger-codegen
documentation generator was insufficient (at least until it catches up
with Swagger 1.2). I wanted it to be easier to generate docs for the API
anyways, so I ported the wiki pages to use the Asterisk Swagger
generator. In the process, I was able to clean up many of the model
links, which would occasionally give inconsistent results on the wiki. I
also added error responses to the wiki docs, making the wiki
documentation more complete.
Finally, since Stasis-HTTP will now be named Asterisk REST Interface
(ARI), any new functions and files I created carry the ari_ prefix. I
changed a few stasis_http references to ari where it was non-intrusive
and made sense.
(closes issue ASTERISK-21885)
Review: https://reviewboard.asterisk.org/r/2639/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393529 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-07-03 16:32:41 +00:00
# if defined(AST_DEVMODE)
code = response - > response_code ;
switch ( code ) {
2013-07-23 14:57:03 +00:00
case 0 : /* Implementation is still a stub, or the code wasn't set */
is_valid = response - > message = = NULL ;
break ;
case 500 : /* Internal Server Error */
case 501 : /* Not Implemented */
2013-10-25 21:28:32 +00:00
case 400 : /* Invalid parameters */
2013-10-15 20:03:19 +00:00
case 404 : /* Bridge not found */
2013-10-25 21:28:32 +00:00
case 409 : /* Bridge is not in a Stasis application; A recording with the same name already exists on the system and can not be overwritten because it is in progress or ifExists=fail */
2013-10-25 22:01:43 +00:00
case 422 : /* The format specified is unknown on this system */
Update events to use Swagger 1.3 subtyping, and related aftermath
This patch started with the simple idea of changing the /events data
model to be more sane. The original model would send out events like:
{ "stasis_start": { "args": [], "channel": { ... } } }
The event discriminator was the field name instead of being a value in
the object, due to limitations in how Swagger 1.1 could model objects.
While technically sufficient in communicating event information, it was
really difficult to deal with in terms of client side JSON handling.
This patch takes advantage of a proposed extension[1] to Swagger which
allows type variance through the use of a discriminator field. This had
a domino effect that made this a surprisingly large patch.
[1]: https://groups.google.com/d/msg/wordnik-api/EC3rGajE0os/ey_5dBI_jWcJ
In changing the models, I also had to change the swagger_model.py
processor so it can handle the type discriminator and subtyping. I took
that a big step forward, and using that information to generate an
ari_model module, which can validate a JSON object against the Swagger
model.
The REST and WebSocket generators were changed to take advantage of the
validators. If compiled with AST_DEVMODE enabled, JSON objects that
don't match their corresponding models will not be sent out. For REST
API calls, a 500 Internal Server response is sent. For WebSockets, the
invalid JSON message is replaced with an error message.
Since this took over about half of the job of the existing JSON
generators, and the .to_json virtual function on messages took over the
other half, I reluctantly removed the generators.
The validators turned up all sorts of errors and inconsistencies in our
data models, and the code. These were cleaned up, with checks in the
code generator avoid some of the consistency problems in the future.
* The model for a channel snapshot was trimmed down to match the
information sent via AMI. Many of the field being sent were not
useful in the general case.
* The model for a bridge snapshot was updated to be more consistent
with the other ARI models.
Another impact of introducing subtyping was that the swagger-codegen
documentation generator was insufficient (at least until it catches up
with Swagger 1.2). I wanted it to be easier to generate docs for the API
anyways, so I ported the wiki pages to use the Asterisk Swagger
generator. In the process, I was able to clean up many of the model
links, which would occasionally give inconsistent results on the wiki. I
also added error responses to the wiki docs, making the wiki
documentation more complete.
Finally, since Stasis-HTTP will now be named Asterisk REST Interface
(ARI), any new functions and files I created carry the ari_ prefix. I
changed a few stasis_http references to ari where it was non-intrusive
and made sense.
(closes issue ASTERISK-21885)
Review: https://reviewboard.asterisk.org/r/2639/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393529 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-07-03 16:32:41 +00:00
is_valid = 1 ;
break ;
default :
if ( 200 < = code & & code < = 299 ) {
2013-07-27 23:11:02 +00:00
is_valid = ast_ari_validate_live_recording (
Update events to use Swagger 1.3 subtyping, and related aftermath
This patch started with the simple idea of changing the /events data
model to be more sane. The original model would send out events like:
{ "stasis_start": { "args": [], "channel": { ... } } }
The event discriminator was the field name instead of being a value in
the object, due to limitations in how Swagger 1.1 could model objects.
While technically sufficient in communicating event information, it was
really difficult to deal with in terms of client side JSON handling.
This patch takes advantage of a proposed extension[1] to Swagger which
allows type variance through the use of a discriminator field. This had
a domino effect that made this a surprisingly large patch.
[1]: https://groups.google.com/d/msg/wordnik-api/EC3rGajE0os/ey_5dBI_jWcJ
In changing the models, I also had to change the swagger_model.py
processor so it can handle the type discriminator and subtyping. I took
that a big step forward, and using that information to generate an
ari_model module, which can validate a JSON object against the Swagger
model.
The REST and WebSocket generators were changed to take advantage of the
validators. If compiled with AST_DEVMODE enabled, JSON objects that
don't match their corresponding models will not be sent out. For REST
API calls, a 500 Internal Server response is sent. For WebSockets, the
invalid JSON message is replaced with an error message.
Since this took over about half of the job of the existing JSON
generators, and the .to_json virtual function on messages took over the
other half, I reluctantly removed the generators.
The validators turned up all sorts of errors and inconsistencies in our
data models, and the code. These were cleaned up, with checks in the
code generator avoid some of the consistency problems in the future.
* The model for a channel snapshot was trimmed down to match the
information sent via AMI. Many of the field being sent were not
useful in the general case.
* The model for a bridge snapshot was updated to be more consistent
with the other ARI models.
Another impact of introducing subtyping was that the swagger-codegen
documentation generator was insufficient (at least until it catches up
with Swagger 1.2). I wanted it to be easier to generate docs for the API
anyways, so I ported the wiki pages to use the Asterisk Swagger
generator. In the process, I was able to clean up many of the model
links, which would occasionally give inconsistent results on the wiki. I
also added error responses to the wiki docs, making the wiki
documentation more complete.
Finally, since Stasis-HTTP will now be named Asterisk REST Interface
(ARI), any new functions and files I created carry the ari_ prefix. I
changed a few stasis_http references to ari where it was non-intrusive
and made sense.
(closes issue ASTERISK-21885)
Review: https://reviewboard.asterisk.org/r/2639/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393529 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-07-03 16:32:41 +00:00
response - > message ) ;
} else {
ast_log ( LOG_ERROR , " Invalid error response %d for /bridges/{bridgeId}/record \n " , code ) ;
is_valid = 0 ;
}
}
if ( ! is_valid ) {
ast_log ( LOG_ERROR , " Response validation failed for /bridges/{bridgeId}/record \n " ) ;
2013-07-27 23:11:02 +00:00
ast_ari_response_error ( response , 500 ,
Update events to use Swagger 1.3 subtyping, and related aftermath
This patch started with the simple idea of changing the /events data
model to be more sane. The original model would send out events like:
{ "stasis_start": { "args": [], "channel": { ... } } }
The event discriminator was the field name instead of being a value in
the object, due to limitations in how Swagger 1.1 could model objects.
While technically sufficient in communicating event information, it was
really difficult to deal with in terms of client side JSON handling.
This patch takes advantage of a proposed extension[1] to Swagger which
allows type variance through the use of a discriminator field. This had
a domino effect that made this a surprisingly large patch.
[1]: https://groups.google.com/d/msg/wordnik-api/EC3rGajE0os/ey_5dBI_jWcJ
In changing the models, I also had to change the swagger_model.py
processor so it can handle the type discriminator and subtyping. I took
that a big step forward, and using that information to generate an
ari_model module, which can validate a JSON object against the Swagger
model.
The REST and WebSocket generators were changed to take advantage of the
validators. If compiled with AST_DEVMODE enabled, JSON objects that
don't match their corresponding models will not be sent out. For REST
API calls, a 500 Internal Server response is sent. For WebSockets, the
invalid JSON message is replaced with an error message.
Since this took over about half of the job of the existing JSON
generators, and the .to_json virtual function on messages took over the
other half, I reluctantly removed the generators.
The validators turned up all sorts of errors and inconsistencies in our
data models, and the code. These were cleaned up, with checks in the
code generator avoid some of the consistency problems in the future.
* The model for a channel snapshot was trimmed down to match the
information sent via AMI. Many of the field being sent were not
useful in the general case.
* The model for a bridge snapshot was updated to be more consistent
with the other ARI models.
Another impact of introducing subtyping was that the swagger-codegen
documentation generator was insufficient (at least until it catches up
with Swagger 1.2). I wanted it to be easier to generate docs for the API
anyways, so I ported the wiki pages to use the Asterisk Swagger
generator. In the process, I was able to clean up many of the model
links, which would occasionally give inconsistent results on the wiki. I
also added error responses to the wiki docs, making the wiki
documentation more complete.
Finally, since Stasis-HTTP will now be named Asterisk REST Interface
(ARI), any new functions and files I created carry the ari_ prefix. I
changed a few stasis_http references to ari where it was non-intrusive
and made sense.
(closes issue ASTERISK-21885)
Review: https://reviewboard.asterisk.org/r/2639/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393529 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-07-03 16:32:41 +00:00
" Internal Server Error " , " Response validation failed " ) ;
}
# endif /* AST_DEVMODE */
2013-08-02 14:36:32 +00:00
fin : __attribute__ ( ( unused ) )
return ;
2013-04-22 14:58:53 +00:00
}
2016-08-18 17:02:24 -05:00
/*! \brief REST handler for /api-docs/bridges.json */
2013-04-22 14:58:53 +00:00
static struct stasis_rest_handlers bridges_bridgeId_addChannel = {
. path_segment = " addChannel " ,
. callbacks = {
2013-11-07 21:10:31 +00:00
[ AST_HTTP_POST ] = ast_ari_bridges_add_channel_cb ,
2013-04-22 14:58:53 +00:00
} ,
. num_children = 0 ,
. children = { }
} ;
2016-08-18 17:02:24 -05:00
/*! \brief REST handler for /api-docs/bridges.json */
2013-04-22 14:58:53 +00:00
static struct stasis_rest_handlers bridges_bridgeId_removeChannel = {
. path_segment = " removeChannel " ,
. callbacks = {
2013-11-07 21:10:31 +00:00
[ AST_HTTP_POST ] = ast_ari_bridges_remove_channel_cb ,
2013-04-22 14:58:53 +00:00
} ,
. num_children = 0 ,
. children = { }
} ;
2016-08-18 17:02:24 -05:00
/*! \brief REST handler for /api-docs/bridges.json */
2016-11-08 10:11:41 -06:00
static struct stasis_rest_handlers bridges_bridgeId_videoSource_channelId = {
. path_segment = " channelId " ,
. is_wildcard = 1 ,
. callbacks = {
[ AST_HTTP_POST ] = ast_ari_bridges_set_video_source_cb ,
} ,
. num_children = 0 ,
. children = { }
} ;
/*! \brief REST handler for /api-docs/bridges.json */
static struct stasis_rest_handlers bridges_bridgeId_videoSource = {
. path_segment = " videoSource " ,
. callbacks = {
[ AST_HTTP_DELETE ] = ast_ari_bridges_clear_video_source_cb ,
} ,
. num_children = 1 ,
. children = { & bridges_bridgeId_videoSource_channelId , }
} ;
/*! \brief REST handler for /api-docs/bridges.json */
2013-10-16 00:12:36 +00:00
static struct stasis_rest_handlers bridges_bridgeId_moh = {
. path_segment = " moh " ,
2013-08-23 00:26:19 +00:00
. callbacks = {
2013-11-07 21:10:31 +00:00
[ AST_HTTP_POST ] = ast_ari_bridges_start_moh_cb ,
[ AST_HTTP_DELETE ] = ast_ari_bridges_stop_moh_cb ,
2013-08-23 00:26:19 +00:00
} ,
. num_children = 0 ,
. children = { }
} ;
2016-08-18 17:02:24 -05:00
/*! \brief REST handler for /api-docs/bridges.json */
2014-04-18 20:09:24 +00:00
static struct stasis_rest_handlers bridges_bridgeId_play_playbackId = {
. path_segment = " playbackId " ,
. is_wildcard = 1 ,
. callbacks = {
[ AST_HTTP_POST ] = ast_ari_bridges_play_with_id_cb ,
} ,
. num_children = 0 ,
. children = { }
} ;
2016-08-18 17:02:24 -05:00
/*! \brief REST handler for /api-docs/bridges.json */
2013-07-19 19:35:21 +00:00
static struct stasis_rest_handlers bridges_bridgeId_play = {
. path_segment = " play " ,
. callbacks = {
2013-11-07 21:10:31 +00:00
[ AST_HTTP_POST ] = ast_ari_bridges_play_cb ,
2013-07-19 19:35:21 +00:00
} ,
2014-04-18 20:09:24 +00:00
. num_children = 1 ,
. children = { & bridges_bridgeId_play_playbackId , }
2013-07-19 19:35:21 +00:00
} ;
2016-08-18 17:02:24 -05:00
/*! \brief REST handler for /api-docs/bridges.json */
2013-04-22 14:58:53 +00:00
static struct stasis_rest_handlers bridges_bridgeId_record = {
. path_segment = " record " ,
. callbacks = {
2013-11-07 21:10:31 +00:00
[ AST_HTTP_POST ] = ast_ari_bridges_record_cb ,
2013-04-22 14:58:53 +00:00
} ,
. num_children = 0 ,
. children = { }
} ;
2016-08-18 17:02:24 -05:00
/*! \brief REST handler for /api-docs/bridges.json */
2013-04-22 14:58:53 +00:00
static struct stasis_rest_handlers bridges_bridgeId = {
. path_segment = " bridgeId " ,
. is_wildcard = 1 ,
. callbacks = {
2015-01-27 17:21:03 +00:00
[ AST_HTTP_POST ] = ast_ari_bridges_create_with_id_cb ,
2013-11-07 21:10:31 +00:00
[ AST_HTTP_GET ] = ast_ari_bridges_get_cb ,
[ AST_HTTP_DELETE ] = ast_ari_bridges_destroy_cb ,
2013-04-22 14:58:53 +00:00
} ,
2016-11-08 10:11:41 -06:00
. num_children = 6 ,
. children = { & bridges_bridgeId_addChannel , & bridges_bridgeId_removeChannel , & bridges_bridgeId_videoSource , & bridges_bridgeId_moh , & bridges_bridgeId_play , & bridges_bridgeId_record , }
2013-04-22 14:58:53 +00:00
} ;
2016-08-18 17:02:24 -05:00
/*! \brief REST handler for /api-docs/bridges.json */
2013-04-22 14:58:53 +00:00
static struct stasis_rest_handlers bridges = {
. path_segment = " bridges " ,
. callbacks = {
2013-11-07 21:10:31 +00:00
[ AST_HTTP_GET ] = ast_ari_bridges_list_cb ,
[ AST_HTTP_POST ] = ast_ari_bridges_create_cb ,
2013-04-22 14:58:53 +00:00
} ,
. num_children = 1 ,
. children = { & bridges_bridgeId , }
} ;
2017-04-16 18:59:54 -06:00
static int unload_module ( void )
{
ast_ari_remove_handler ( & bridges ) ;
return 0 ;
}
2013-04-22 14:58:53 +00:00
static int load_module ( void )
{
2013-07-03 16:32:00 +00:00
int res = 0 ;
2017-06-13 10:33:34 -06:00
2013-07-27 23:11:02 +00:00
res | = ast_ari_add_handler ( & bridges ) ;
2017-04-16 18:59:54 -06:00
if ( res ) {
unload_module ( ) ;
return AST_MODULE_LOAD_DECLINE ;
}
2013-04-22 14:58:53 +00:00
2017-04-16 18:59:54 -06:00
return AST_MODULE_LOAD_SUCCESS ;
2013-04-22 14:58:53 +00:00
}
2013-06-24 21:40:52 +00:00
AST_MODULE_INFO ( ASTERISK_GPL_KEY , AST_MODFLAG_DEFAULT , " RESTful API module - Bridge resources " ,
2014-07-25 16:47:17 +00:00
. support_level = AST_MODULE_SUPPORT_CORE ,
2013-04-22 14:58:53 +00:00
. load = load_module ,
. unload = unload_module ,
2018-01-18 10:01:26 -05:00
. requires = " res_ari,res_ari_model,res_stasis,res_stasis_recording,res_stasis_playback " ,
2015-05-05 20:49:04 -04:00
) ;
