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 Channel 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 11:46:44 +00:00
< depend type = " module " > res_ari_model < / depend >
2013-05-10 17:12:57 +00:00
< depend type = " module " > res_stasis < / depend >
2013-04-22 14:58:53 +00:00
< support_level > core < / support_level >
* * */
# include "asterisk.h"
git migration: Refactor the ASTERISK_FILE_VERSION macro
Git does not support the ability to replace a token with a version
string during check-in. While it does have support for replacing a
token on clone, this is somewhat sub-optimal: the token is replaced
with the object hash, which is not particularly easy for human
consumption. What's more, in practice, the source file version was often
not terribly useful. Generally, when triaging bugs, the overall version
of Asterisk is far more useful than an individual SVN version of a file. As a
result, this patch removes Asterisk's support for showing source file
versions.
Specifically, it does the following:
* Rename ASTERISK_FILE_VERSION macro to ASTERISK_REGISTER_FILE, and
remove passing the version in with the macro. Other facilities
than 'core show file version' make use of the file names, such as
setting a debug level only on a specific file. As such, the act of
registering source files with the Asterisk core still has use. The
macro rename now reflects the new macro purpose.
* main/asterisk:
- Refactor the file_version structure to reflect that it no longer
tracks a version field.
- Remove the "core show file version" CLI command. Without the file
version, it is no longer useful.
- Remove the ast_file_version_find function. The file version is no
longer tracked.
- Rename ast_register_file_version/ast_unregister_file_version to
ast_register_file/ast_unregister_file, respectively.
* main/manager: Remove value from the Version key of the ModuleCheck
Action. The actual key itself has not been removed, as doing so would
absolutely constitute a backwards incompatible change. However, since
the file version is no longer tracked, there is no need to attempt to
include it in the Version key.
* UPGRADE: Add notes for:
- Modification to the ModuleCheck AMI Action
- Removal of the "core show file version" CLI command
Change-Id: I6cf0ff280e1668bf4957dc21f32a5ff43444a40e
2015-04-12 02:38:22 +00:00
ASTERISK_REGISTER_FILE ( )
2013-04-22 14:58:53 +00:00
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_channels.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 / channels .
* \ param get_params GET parameters in the HTTP request .
* \ param path_vars Path variables extracted from the request .
* \ param headers HTTP headers .
* \ param [ out ] response Response to the HTTP request .
*/
2013-11-07 21:10:31 +00:00
static void ast_ari_channels_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 ,
2013-07-27 23:11:02 +00:00
struct ast_variable * headers , struct ast_ari_response * response )
2013-04-22 14:58:53 +00:00
{
2013-11-07 21:10:31 +00:00
struct ast_ari_channels_list_args args = { } ;
2013-11-27 15:48:39 +00:00
RAII_VAR ( struct ast_json * , body , NULL , ast_json_unref ) ;
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_channels_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_channel_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 /channels \n " , code ) ;
is_valid = 0 ;
}
}
if ( ! is_valid ) {
ast_log ( LOG_ERROR , " Response validation failed for /channels \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_channels_originate_parse_body (
struct ast_json * body ,
struct ast_ari_channels_originate_args * args )
{
struct ast_json * field ;
/* Parse query parameters out of it */
field = ast_json_object_get ( body , " endpoint " ) ;
if ( field ) {
args - > endpoint = ast_json_string_get ( field ) ;
}
field = ast_json_object_get ( body , " extension " ) ;
if ( field ) {
args - > extension = ast_json_string_get ( field ) ;
}
field = ast_json_object_get ( body , " context " ) ;
if ( field ) {
args - > context = ast_json_string_get ( field ) ;
}
field = ast_json_object_get ( body , " priority " ) ;
if ( field ) {
args - > priority = ast_json_integer_get ( field ) ;
}
2015-01-07 18:54:06 +00:00
field = ast_json_object_get ( body , " label " ) ;
if ( field ) {
args - > label = ast_json_string_get ( field ) ;
}
2014-01-21 14:27:21 +00:00
field = ast_json_object_get ( body , " app " ) ;
if ( field ) {
args - > app = ast_json_string_get ( field ) ;
}
field = ast_json_object_get ( body , " appArgs " ) ;
if ( field ) {
args - > app_args = ast_json_string_get ( field ) ;
}
field = ast_json_object_get ( body , " callerId " ) ;
if ( field ) {
args - > caller_id = ast_json_string_get ( field ) ;
}
field = ast_json_object_get ( body , " timeout " ) ;
if ( field ) {
args - > timeout = ast_json_integer_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 , " channelId " ) ;
if ( field ) {
args - > channel_id = ast_json_string_get ( field ) ;
}
field = ast_json_object_get ( body , " otherChannelId " ) ;
if ( field ) {
args - > other_channel_id = ast_json_string_get ( field ) ;
}
2014-12-09 15:45:19 +00:00
field = ast_json_object_get ( body , " originator " ) ;
if ( field ) {
args - > originator = ast_json_string_get ( field ) ;
}
2014-01-21 14:27:21 +00:00
return 0 ;
}
2013-04-22 14:58:53 +00:00
/*!
* \ brief Parameter parsing callback for / channels .
* \ param get_params GET parameters in the HTTP request .
* \ param path_vars Path variables extracted from the request .
* \ param headers HTTP headers .
* \ param [ out ] response Response to the HTTP request .
*/
2013-11-07 21:10:31 +00:00
static void ast_ari_channels_originate_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 ,
2013-07-27 23:11:02 +00:00
struct ast_variable * headers , struct ast_ari_response * response )
2013-04-22 14:58:53 +00:00
{
2013-11-07 21:10:31 +00:00
struct ast_ari_channels_originate_args args = { } ;
2013-08-02 14:36:32 +00:00
struct ast_variable * i ;
2013-11-27 15:48:39 +00:00
RAII_VAR ( struct ast_json * , body , NULL , ast_json_unref ) ;
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 , " endpoint " ) = = 0 ) {
args . endpoint = ( i - > value ) ;
} else
if ( strcmp ( i - > name , " extension " ) = = 0 ) {
args . extension = ( i - > value ) ;
} else
if ( strcmp ( i - > name , " context " ) = = 0 ) {
args . context = ( i - > value ) ;
} else
2013-06-28 16:23:24 +00:00
if ( strcmp ( i - > name , " priority " ) = = 0 ) {
args . priority = atol ( i - > value ) ;
2013-06-07 18:39:42 +00:00
} else
2015-01-07 18:54:06 +00:00
if ( strcmp ( i - > name , " label " ) = = 0 ) {
args . label = ( i - > value ) ;
} else
2013-06-07 18:39:42 +00:00
if ( strcmp ( i - > name , " app " ) = = 0 ) {
args . app = ( i - > value ) ;
} else
if ( strcmp ( i - > name , " appArgs " ) = = 0 ) {
args . app_args = ( i - > value ) ;
} else
2013-06-28 16:23:24 +00:00
if ( strcmp ( i - > name , " callerId " ) = = 0 ) {
args . caller_id = ( i - > value ) ;
} else
if ( strcmp ( i - > name , " timeout " ) = = 0 ) {
args . timeout = atoi ( 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 , " channelId " ) = = 0 ) {
args . channel_id = ( i - > value ) ;
} else
if ( strcmp ( i - > name , " otherChannelId " ) = = 0 ) {
args . other_channel_id = ( i - > value ) ;
} else
2014-12-09 15:45:19 +00:00
if ( strcmp ( i - > name , " originator " ) = = 0 ) {
args . originator = ( i - > value ) ;
} else
2013-04-22 14:58:53 +00:00
{ }
}
2013-11-27 15:48:39 +00:00
/* Look for a JSON request entity */
body = ast_http_get_json ( ser , headers ) ;
if ( ! body ) {
switch ( errno ) {
case EFBIG :
ast_ari_response_error ( response , 413 , " Request Entity Too Large " , " Request body too large " ) ;
goto fin ;
case ENOMEM :
ast_ari_response_error ( response , 500 , " Internal Server Error " , " Error processing request " ) ;
goto fin ;
case EIO :
ast_ari_response_error ( response , 400 , " Bad Request " , " Error parsing request body " ) ;
goto fin ;
}
}
2015-01-23 15:21:56 +00:00
args . variables = body ;
2013-11-07 21:10:31 +00:00
ast_ari_channels_originate ( 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-07-10 17:13:21 +00:00
case 400 : /* Invalid parameters for originating a channel. */
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-10-19 14:45:14 +00:00
is_valid = ast_ari_validate_channel (
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 /channels \n " , code ) ;
is_valid = 0 ;
}
}
if ( ! is_valid ) {
ast_log ( LOG_ERROR , " Response validation failed for /channels \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 / channels / { channelId } .
* \ param get_params GET parameters in the HTTP request .
* \ param path_vars Path variables extracted from the request .
* \ param headers HTTP headers .
* \ param [ out ] response Response to the HTTP request .
*/
2013-11-07 21:10:31 +00:00
static void ast_ari_channels_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 ,
2013-07-27 23:11:02 +00:00
struct ast_variable * headers , struct ast_ari_response * response )
2013-04-22 14:58:53 +00:00
{
2013-11-07 21:10:31 +00:00
struct ast_ari_channels_get_args args = { } ;
2013-08-02 14:36:32 +00:00
struct ast_variable * i ;
2013-11-27 15:48:39 +00:00
RAII_VAR ( struct ast_json * , body , NULL , ast_json_unref ) ;
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 , " channelId " ) = = 0 ) {
args . channel_id = ( i - > value ) ;
} else
{ }
}
2013-11-07 21:10:31 +00:00
ast_ari_channels_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 : /* Channel 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_channel (
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 /channels/{channelId} \n " , code ) ;
is_valid = 0 ;
}
}
if ( ! is_valid ) {
ast_log ( LOG_ERROR , " Response validation failed for /channels/{channelId} \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 ;
}
int ast_ari_channels_originate_with_id_parse_body (
struct ast_json * body ,
struct ast_ari_channels_originate_with_id_args * args )
{
struct ast_json * field ;
/* Parse query parameters out of it */
field = ast_json_object_get ( body , " endpoint " ) ;
if ( field ) {
args - > endpoint = ast_json_string_get ( field ) ;
}
field = ast_json_object_get ( body , " extension " ) ;
if ( field ) {
args - > extension = ast_json_string_get ( field ) ;
}
field = ast_json_object_get ( body , " context " ) ;
if ( field ) {
args - > context = ast_json_string_get ( field ) ;
}
field = ast_json_object_get ( body , " priority " ) ;
if ( field ) {
args - > priority = ast_json_integer_get ( field ) ;
}
2015-01-07 18:54:06 +00:00
field = ast_json_object_get ( body , " label " ) ;
if ( field ) {
args - > label = 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 , " app " ) ;
if ( field ) {
args - > app = ast_json_string_get ( field ) ;
}
field = ast_json_object_get ( body , " appArgs " ) ;
if ( field ) {
args - > app_args = ast_json_string_get ( field ) ;
}
field = ast_json_object_get ( body , " callerId " ) ;
if ( field ) {
args - > caller_id = ast_json_string_get ( field ) ;
}
field = ast_json_object_get ( body , " timeout " ) ;
if ( field ) {
args - > timeout = ast_json_integer_get ( field ) ;
}
field = ast_json_object_get ( body , " otherChannelId " ) ;
if ( field ) {
args - > other_channel_id = ast_json_string_get ( field ) ;
}
2014-12-09 15:45:19 +00:00
field = ast_json_object_get ( body , " originator " ) ;
if ( field ) {
args - > originator = 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
return 0 ;
}
/*!
* \ brief Parameter parsing callback for / channels / { channelId } .
* \ param get_params GET parameters in the HTTP request .
* \ param path_vars Path variables extracted from the request .
* \ param headers HTTP headers .
* \ param [ out ] response Response to the HTTP request .
*/
static void ast_ari_channels_originate_with_id_cb (
struct ast_tcptls_session_instance * ser ,
struct ast_variable * get_params , struct ast_variable * path_vars ,
struct ast_variable * headers , struct ast_ari_response * response )
{
struct ast_ari_channels_originate_with_id_args args = { } ;
struct ast_variable * i ;
RAII_VAR ( struct ast_json * , body , NULL , ast_json_unref ) ;
# if defined(AST_DEVMODE)
int is_valid ;
int code ;
# endif /* AST_DEVMODE */
for ( i = get_params ; i ; i = i - > next ) {
if ( strcmp ( i - > name , " endpoint " ) = = 0 ) {
args . endpoint = ( i - > value ) ;
} else
if ( strcmp ( i - > name , " extension " ) = = 0 ) {
args . extension = ( i - > value ) ;
} else
if ( strcmp ( i - > name , " context " ) = = 0 ) {
args . context = ( i - > value ) ;
} else
if ( strcmp ( i - > name , " priority " ) = = 0 ) {
args . priority = atol ( i - > value ) ;
} else
2015-01-07 18:54:06 +00:00
if ( strcmp ( i - > name , " label " ) = = 0 ) {
args . label = ( 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 , " app " ) = = 0 ) {
args . app = ( i - > value ) ;
} else
if ( strcmp ( i - > name , " appArgs " ) = = 0 ) {
args . app_args = ( i - > value ) ;
} else
if ( strcmp ( i - > name , " callerId " ) = = 0 ) {
args . caller_id = ( i - > value ) ;
} else
if ( strcmp ( i - > name , " timeout " ) = = 0 ) {
args . timeout = atoi ( i - > value ) ;
} else
if ( strcmp ( i - > name , " otherChannelId " ) = = 0 ) {
args . other_channel_id = ( i - > value ) ;
} else
2014-12-09 15:45:19 +00:00
if ( strcmp ( i - > name , " originator " ) = = 0 ) {
args . originator = ( 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
{ }
}
for ( i = path_vars ; i ; i = i - > next ) {
if ( strcmp ( i - > name , " channelId " ) = = 0 ) {
args . channel_id = ( i - > value ) ;
} else
{ }
}
/* Look for a JSON request entity */
body = ast_http_get_json ( ser , headers ) ;
if ( ! body ) {
switch ( errno ) {
case EFBIG :
ast_ari_response_error ( response , 413 , " Request Entity Too Large " , " Request body too large " ) ;
goto fin ;
case ENOMEM :
ast_ari_response_error ( response , 500 , " Internal Server Error " , " Error processing request " ) ;
goto fin ;
case EIO :
ast_ari_response_error ( response , 400 , " Bad Request " , " Error parsing request body " ) ;
goto fin ;
}
}
2015-01-23 15:21:56 +00:00
args . variables = 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
ast_ari_channels_originate_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 400 : /* Invalid parameters for originating a channel. */
is_valid = 1 ;
break ;
default :
if ( 200 < = code & & code < = 299 ) {
is_valid = ast_ari_validate_channel (
response - > message ) ;
} else {
ast_log ( LOG_ERROR , " Invalid error response %d for /channels/{channelId} \n " , code ) ;
is_valid = 0 ;
}
}
if ( ! is_valid ) {
ast_log ( LOG_ERROR , " Response validation failed for /channels/{channelId} \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
}
2014-01-21 14:27:21 +00:00
int ast_ari_channels_hangup_parse_body (
struct ast_json * body ,
struct ast_ari_channels_hangup_args * args )
{
struct ast_json * field ;
/* Parse query parameters out of it */
field = ast_json_object_get ( body , " reason " ) ;
if ( field ) {
args - > reason = ast_json_string_get ( field ) ;
}
return 0 ;
}
2013-04-22 14:58:53 +00:00
/*!
* \ brief Parameter parsing callback for / channels / { channelId } .
* \ param get_params GET parameters in the HTTP request .
* \ param path_vars Path variables extracted from the request .
* \ param headers HTTP headers .
* \ param [ out ] response Response to the HTTP request .
*/
2013-11-07 21:10:31 +00:00
static void ast_ari_channels_hangup_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 ,
2013-07-27 23:11:02 +00:00
struct ast_variable * headers , struct ast_ari_response * response )
2013-04-22 14:58:53 +00:00
{
2013-11-07 21:10:31 +00:00
struct ast_ari_channels_hangup_args args = { } ;
2013-08-02 14:36:32 +00:00
struct ast_variable * i ;
2013-11-27 15:48:39 +00:00
RAII_VAR ( struct ast_json * , body , NULL , ast_json_unref ) ;
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-01 14:38:21 +00:00
for ( i = get_params ; i ; i = i - > next ) {
if ( strcmp ( i - > name , " reason " ) = = 0 ) {
args . reason = ( i - > value ) ;
} else
{ }
}
2013-04-22 14:58:53 +00:00
for ( i = path_vars ; i ; i = i - > next ) {
if ( strcmp ( i - > name , " channelId " ) = = 0 ) {
args . channel_id = ( i - > value ) ;
} else
{ }
}
2013-11-27 15:48:39 +00:00
/* Look for a JSON request entity */
body = ast_http_get_json ( ser , headers ) ;
if ( ! body ) {
switch ( errno ) {
case EFBIG :
ast_ari_response_error ( response , 413 , " Request Entity Too Large " , " Request body too large " ) ;
goto fin ;
case ENOMEM :
ast_ari_response_error ( response , 500 , " Internal Server Error " , " Error processing request " ) ;
goto fin ;
case EIO :
ast_ari_response_error ( response , 400 , " Bad Request " , " Error parsing request body " ) ;
goto fin ;
}
}
2014-01-21 14:27:21 +00:00
if ( ast_ari_channels_hangup_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_channels_hangup ( 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-11-01 14:38:21 +00:00
case 400 : /* Invalid reason for hangup provided */
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 : /* Channel 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 /channels/{channelId} \n " , code ) ;
is_valid = 0 ;
}
}
if ( ! is_valid ) {
ast_log ( LOG_ERROR , " Response validation failed for /channels/{channelId} \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_channels_continue_in_dialplan_parse_body (
struct ast_json * body ,
struct ast_ari_channels_continue_in_dialplan_args * args )
{
struct ast_json * field ;
/* Parse query parameters out of it */
field = ast_json_object_get ( body , " context " ) ;
if ( field ) {
args - > context = ast_json_string_get ( field ) ;
}
field = ast_json_object_get ( body , " extension " ) ;
if ( field ) {
args - > extension = ast_json_string_get ( field ) ;
}
field = ast_json_object_get ( body , " priority " ) ;
if ( field ) {
args - > priority = ast_json_integer_get ( field ) ;
}
2015-01-07 18:54:06 +00:00
field = ast_json_object_get ( body , " label " ) ;
if ( field ) {
args - > label = ast_json_string_get ( field ) ;
}
2014-01-21 14:27:21 +00:00
return 0 ;
}
2013-04-22 14:58:53 +00:00
/*!
* \ brief Parameter parsing callback for / channels / { channelId } / continue .
* \ param get_params GET parameters in the HTTP request .
* \ param path_vars Path variables extracted from the request .
* \ param headers HTTP headers .
* \ param [ out ] response Response to the HTTP request .
*/
2013-11-07 21:10:31 +00:00
static void ast_ari_channels_continue_in_dialplan_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 ,
2013-07-27 23:11:02 +00:00
struct ast_variable * headers , struct ast_ari_response * response )
2013-04-22 14:58:53 +00:00
{
2013-11-07 21:10:31 +00:00
struct ast_ari_channels_continue_in_dialplan_args args = { } ;
2013-08-02 14:36:32 +00:00
struct ast_variable * i ;
2013-11-27 15:48:39 +00:00
RAII_VAR ( struct ast_json * , body , NULL , ast_json_unref ) ;
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-06-26 19:29:57 +00:00
for ( i = get_params ; i ; i = i - > next ) {
if ( strcmp ( i - > name , " context " ) = = 0 ) {
args . context = ( i - > value ) ;
} else
if ( strcmp ( i - > name , " extension " ) = = 0 ) {
args . extension = ( i - > value ) ;
} else
if ( strcmp ( i - > name , " priority " ) = = 0 ) {
args . priority = atoi ( i - > value ) ;
} else
2015-01-07 18:54:06 +00:00
if ( strcmp ( i - > name , " label " ) = = 0 ) {
args . label = ( i - > value ) ;
} else
2013-06-26 19:29:57 +00:00
{ }
}
2013-04-22 14:58:53 +00:00
for ( i = path_vars ; i ; i = i - > next ) {
if ( strcmp ( i - > name , " channelId " ) = = 0 ) {
args . channel_id = ( i - > value ) ;
} else
{ }
}
2013-11-27 15:48:39 +00:00
/* Look for a JSON request entity */
body = ast_http_get_json ( ser , headers ) ;
if ( ! body ) {
switch ( errno ) {
case EFBIG :
ast_ari_response_error ( response , 413 , " Request Entity Too Large " , " Request body too large " ) ;
goto fin ;
case ENOMEM :
ast_ari_response_error ( response , 500 , " Internal Server Error " , " Error processing request " ) ;
goto fin ;
case EIO :
ast_ari_response_error ( response , 400 , " Bad Request " , " Error parsing request body " ) ;
goto fin ;
}
}
2014-01-21 14:27:21 +00:00
if ( ast_ari_channels_continue_in_dialplan_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_channels_continue_in_dialplan ( 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 : /* Channel not found */
case 409 : /* Channel not in a Stasis application */
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 /channels/{channelId}/continue \n " , code ) ;
is_valid = 0 ;
}
}
if ( ! is_valid ) {
ast_log ( LOG_ERROR , " Response validation failed for /channels/{channelId}/continue \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
ARI/PJSIP: Add the ability to redirect (transfer) a channel in a Stasis app
This patch adds a new feature to ARI to redirect a channel to another server,
and fixes a few bugs in PJSIP's handling of the Transfer dialplan
application/ARI redirect capability.
*New Feature*
A new operation has been added to the ARI channels resource, redirect. With
this, a channel in a Stasis application can be redirected to another endpoint
of the same underlying channel technology.
*Bug fixes*
In the process of writing this new feature, two bugs were fixed in the PJSIP
stack:
(1) The existing .transfer channel callback had the limitation that it could
only transfer channels to a SIP URI, i.e., you had to pass
'PJSIP/sip:foo@my_provider.com' to the dialplan application. While this is
still supported, it is somewhat unintuitive - particularly in a world full
of endpoints. As such, we now also support specifying the PJSIP endpoint to
transfer to.
(2) res_pjsip_multihomed was, unfortunately, trying to 'help' a 302 redirect by
updating its Contact header. Alas, that resulted in the forwarding
destination set by the dialplan application/ARI resource/whatever being
rewritten with very incorrect information. Hence, we now don't bother
updating an outgoing response if it is a 302. Since this took a looong time
to find, some additional debug statements have been added to those modules
that update the Contact headers.
Review: https://reviewboard.asterisk.org/r/4316/
ASTERISK-24015 #close
Reported by: Private Name
ASTERISK-24703 #close
Reported by: Matt Jordan
........
Merged revisions 431717 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431718 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2015-02-12 20:34:37 +00:00
fin : __attribute__ ( ( unused ) )
return ;
}
int ast_ari_channels_redirect_parse_body (
struct ast_json * body ,
struct ast_ari_channels_redirect_args * args )
{
struct ast_json * field ;
/* Parse query parameters out of it */
field = ast_json_object_get ( body , " endpoint " ) ;
if ( field ) {
args - > endpoint = ast_json_string_get ( field ) ;
}
return 0 ;
}
/*!
* \ brief Parameter parsing callback for / channels / { channelId } / redirect .
* \ param get_params GET parameters in the HTTP request .
* \ param path_vars Path variables extracted from the request .
* \ param headers HTTP headers .
* \ param [ out ] response Response to the HTTP request .
*/
static void ast_ari_channels_redirect_cb (
struct ast_tcptls_session_instance * ser ,
struct ast_variable * get_params , struct ast_variable * path_vars ,
struct ast_variable * headers , struct ast_ari_response * response )
{
struct ast_ari_channels_redirect_args args = { } ;
struct ast_variable * i ;
RAII_VAR ( struct ast_json * , body , NULL , ast_json_unref ) ;
# if defined(AST_DEVMODE)
int is_valid ;
int code ;
# endif /* AST_DEVMODE */
for ( i = get_params ; i ; i = i - > next ) {
if ( strcmp ( i - > name , " endpoint " ) = = 0 ) {
args . endpoint = ( i - > value ) ;
} else
{ }
}
for ( i = path_vars ; i ; i = i - > next ) {
if ( strcmp ( i - > name , " channelId " ) = = 0 ) {
args . channel_id = ( i - > value ) ;
} else
{ }
}
/* Look for a JSON request entity */
body = ast_http_get_json ( ser , headers ) ;
if ( ! body ) {
switch ( errno ) {
case EFBIG :
ast_ari_response_error ( response , 413 , " Request Entity Too Large " , " Request body too large " ) ;
goto fin ;
case ENOMEM :
ast_ari_response_error ( response , 500 , " Internal Server Error " , " Error processing request " ) ;
goto fin ;
case EIO :
ast_ari_response_error ( response , 400 , " Bad Request " , " Error parsing request body " ) ;
goto fin ;
}
}
if ( ast_ari_channels_redirect_parse_body ( body , & args ) ) {
ast_ari_response_alloc_failed ( response ) ;
goto fin ;
}
ast_ari_channels_redirect ( 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 400 : /* Endpoint parameter not provided */
case 404 : /* Channel or endpoint not found */
case 409 : /* Channel not in a Stasis application */
case 422 : /* Endpoint is not the same type as the channel */
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 /channels/{channelId}/redirect \n " , code ) ;
is_valid = 0 ;
}
}
if ( ! is_valid ) {
ast_log ( LOG_ERROR , " Response validation failed for /channels/{channelId}/redirect \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 / channels / { channelId } / answer .
* \ param get_params GET parameters in the HTTP request .
* \ param path_vars Path variables extracted from the request .
* \ param headers HTTP headers .
* \ param [ out ] response Response to the HTTP request .
*/
2013-11-07 21:10:31 +00:00
static void ast_ari_channels_answer_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 ,
2013-07-27 23:11:02 +00:00
struct ast_variable * headers , struct ast_ari_response * response )
2013-04-22 14:58:53 +00:00
{
2013-11-07 21:10:31 +00:00
struct ast_ari_channels_answer_args args = { } ;
2013-08-02 14:36:32 +00:00
struct ast_variable * i ;
2013-11-27 15:48:39 +00:00
RAII_VAR ( struct ast_json * , body , NULL , ast_json_unref ) ;
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 , " channelId " ) = = 0 ) {
args . channel_id = ( i - > value ) ;
} else
{ }
}
2013-11-07 21:10:31 +00:00
ast_ari_channels_answer ( 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 : /* Channel not found */
case 409 : /* Channel not in a Stasis application */
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 /channels/{channelId}/answer \n " , code ) ;
is_valid = 0 ;
}
}
if ( ! is_valid ) {
ast_log ( LOG_ERROR , " Response validation failed for /channels/{channelId}/answer \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
2013-11-01 14:38:21 +00:00
fin : __attribute__ ( ( unused ) )
return ;
}
/*!
* \ brief Parameter parsing callback for / channels / { channelId } / ring .
* \ param get_params GET parameters in the HTTP request .
* \ param path_vars Path variables extracted from the request .
* \ param headers HTTP headers .
* \ param [ out ] response Response to the HTTP request .
*/
2013-11-07 21:10:31 +00:00
static void ast_ari_channels_ring_cb (
2013-11-27 15:48:39 +00:00
struct ast_tcptls_session_instance * ser ,
2013-11-01 14:38:21 +00:00
struct ast_variable * get_params , struct ast_variable * path_vars ,
struct ast_variable * headers , struct ast_ari_response * response )
{
2013-11-07 21:10:31 +00:00
struct ast_ari_channels_ring_args args = { } ;
2013-11-01 14:38:21 +00:00
struct ast_variable * i ;
2013-11-27 15:48:39 +00:00
RAII_VAR ( struct ast_json * , body , NULL , ast_json_unref ) ;
2013-11-01 14:38:21 +00:00
# if defined(AST_DEVMODE)
int is_valid ;
int code ;
# endif /* AST_DEVMODE */
for ( i = path_vars ; i ; i = i - > next ) {
if ( strcmp ( i - > name , " channelId " ) = = 0 ) {
args . channel_id = ( i - > value ) ;
} else
{ }
}
2013-11-07 21:10:31 +00:00
ast_ari_channels_ring ( headers , & args , response ) ;
2013-11-01 14:38:21 +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 : /* Channel not found */
case 409 : /* Channel not in a Stasis application */
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 /channels/{channelId}/ring \n " , code ) ;
is_valid = 0 ;
}
}
if ( ! is_valid ) {
ast_log ( LOG_ERROR , " Response validation failed for /channels/{channelId}/ring \n " ) ;
ast_ari_response_error ( response , 500 ,
" Internal Server Error " , " Response validation failed " ) ;
}
# endif /* AST_DEVMODE */
2013-11-13 23:11:32 +00:00
fin : __attribute__ ( ( unused ) )
return ;
}
/*!
* \ brief Parameter parsing callback for / channels / { channelId } / ring .
* \ param get_params GET parameters in the HTTP request .
* \ param path_vars Path variables extracted from the request .
* \ param headers HTTP headers .
* \ param [ out ] response Response to the HTTP request .
*/
static void ast_ari_channels_ring_stop_cb (
2013-11-27 15:48:39 +00:00
struct ast_tcptls_session_instance * ser ,
2013-11-13 23:11:32 +00:00
struct ast_variable * get_params , struct ast_variable * path_vars ,
struct ast_variable * headers , struct ast_ari_response * response )
{
struct ast_ari_channels_ring_stop_args args = { } ;
struct ast_variable * i ;
2013-11-27 15:48:39 +00:00
RAII_VAR ( struct ast_json * , body , NULL , ast_json_unref ) ;
2013-11-13 23:11:32 +00:00
# if defined(AST_DEVMODE)
int is_valid ;
int code ;
# endif /* AST_DEVMODE */
for ( i = path_vars ; i ; i = i - > next ) {
if ( strcmp ( i - > name , " channelId " ) = = 0 ) {
args . channel_id = ( i - > value ) ;
} else
{ }
}
ast_ari_channels_ring_stop ( 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 : /* Channel not found */
case 409 : /* Channel not in a Stasis application */
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 /channels/{channelId}/ring \n " , code ) ;
is_valid = 0 ;
}
}
if ( ! is_valid ) {
ast_log ( LOG_ERROR , " Response validation failed for /channels/{channelId}/ring \n " ) ;
ast_ari_response_error ( response , 500 ,
" Internal Server Error " , " Response validation failed " ) ;
}
# endif /* AST_DEVMODE */
2013-11-01 14:38:21 +00:00
fin : __attribute__ ( ( unused ) )
return ;
}
2014-01-21 14:27:21 +00:00
int ast_ari_channels_send_dtmf_parse_body (
struct ast_json * body ,
struct ast_ari_channels_send_dtmf_args * args )
{
struct ast_json * field ;
/* Parse query parameters out of it */
field = ast_json_object_get ( body , " dtmf " ) ;
if ( field ) {
args - > dtmf = ast_json_string_get ( field ) ;
}
field = ast_json_object_get ( body , " before " ) ;
if ( field ) {
args - > before = ast_json_integer_get ( field ) ;
}
field = ast_json_object_get ( body , " between " ) ;
if ( field ) {
args - > between = ast_json_integer_get ( field ) ;
}
field = ast_json_object_get ( body , " duration " ) ;
if ( field ) {
args - > duration = ast_json_integer_get ( field ) ;
}
field = ast_json_object_get ( body , " after " ) ;
if ( field ) {
args - > after = ast_json_integer_get ( field ) ;
}
return 0 ;
}
2013-11-01 14:38:21 +00:00
/*!
* \ brief Parameter parsing callback for / channels / { channelId } / dtmf .
* \ param get_params GET parameters in the HTTP request .
* \ param path_vars Path variables extracted from the request .
* \ param headers HTTP headers .
* \ param [ out ] response Response to the HTTP request .
*/
2013-11-07 21:10:31 +00:00
static void ast_ari_channels_send_dtmf_cb (
2013-11-27 15:48:39 +00:00
struct ast_tcptls_session_instance * ser ,
2013-11-01 14:38:21 +00:00
struct ast_variable * get_params , struct ast_variable * path_vars ,
struct ast_variable * headers , struct ast_ari_response * response )
{
2013-11-07 21:10:31 +00:00
struct ast_ari_channels_send_dtmf_args args = { } ;
2013-11-01 14:38:21 +00:00
struct ast_variable * i ;
2013-11-27 15:48:39 +00:00
RAII_VAR ( struct ast_json * , body , NULL , ast_json_unref ) ;
2013-11-01 14:38: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 , " dtmf " ) = = 0 ) {
args . dtmf = ( i - > value ) ;
} else
if ( strcmp ( i - > name , " before " ) = = 0 ) {
args . before = atoi ( i - > value ) ;
} else
if ( strcmp ( i - > name , " between " ) = = 0 ) {
args . between = atoi ( i - > value ) ;
} else
if ( strcmp ( i - > name , " duration " ) = = 0 ) {
args . duration = atoi ( i - > value ) ;
} else
if ( strcmp ( i - > name , " after " ) = = 0 ) {
args . after = atoi ( i - > value ) ;
} else
{ }
}
for ( i = path_vars ; i ; i = i - > next ) {
if ( strcmp ( i - > name , " channelId " ) = = 0 ) {
args . channel_id = ( i - > value ) ;
} else
{ }
}
2013-11-27 15:48:39 +00:00
/* Look for a JSON request entity */
body = ast_http_get_json ( ser , headers ) ;
if ( ! body ) {
switch ( errno ) {
case EFBIG :
ast_ari_response_error ( response , 413 , " Request Entity Too Large " , " Request body too large " ) ;
goto fin ;
case ENOMEM :
ast_ari_response_error ( response , 500 , " Internal Server Error " , " Error processing request " ) ;
goto fin ;
case EIO :
ast_ari_response_error ( response , 400 , " Bad Request " , " Error parsing request body " ) ;
goto fin ;
}
}
2014-01-21 14:27:21 +00:00
if ( ast_ari_channels_send_dtmf_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_channels_send_dtmf ( headers , & args , response ) ;
2013-11-01 14:38:21 +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 400 : /* DTMF is required */
case 404 : /* Channel not found */
case 409 : /* Channel not in a Stasis application */
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 /channels/{channelId}/dtmf \n " , code ) ;
is_valid = 0 ;
}
}
if ( ! is_valid ) {
ast_log ( LOG_ERROR , " Response validation failed for /channels/{channelId}/dtmf \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
}
2014-01-21 14:27:21 +00:00
int ast_ari_channels_mute_parse_body (
struct ast_json * body ,
struct ast_ari_channels_mute_args * args )
{
struct ast_json * field ;
/* Parse query parameters out of it */
field = ast_json_object_get ( body , " direction " ) ;
if ( field ) {
args - > direction = ast_json_string_get ( field ) ;
}
return 0 ;
}
2013-04-22 14:58:53 +00:00
/*!
* \ brief Parameter parsing callback for / channels / { channelId } / mute .
* \ param get_params GET parameters in the HTTP request .
* \ param path_vars Path variables extracted from the request .
* \ param headers HTTP headers .
* \ param [ out ] response Response to the HTTP request .
*/
2013-11-07 21:10:31 +00:00
static void ast_ari_channels_mute_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 ,
2013-07-27 23:11:02 +00:00
struct ast_variable * headers , struct ast_ari_response * response )
2013-04-22 14:58:53 +00:00
{
2013-11-07 21:10:31 +00:00
struct ast_ari_channels_mute_args args = { } ;
2013-08-02 14:36:32 +00:00
struct ast_variable * i ;
2013-11-27 15:48:39 +00:00
RAII_VAR ( struct ast_json * , body , NULL , ast_json_unref ) ;
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 , " direction " ) = = 0 ) {
args . direction = ( i - > value ) ;
} else
{ }
}
for ( i = path_vars ; i ; i = i - > next ) {
if ( strcmp ( i - > name , " channelId " ) = = 0 ) {
args . channel_id = ( i - > value ) ;
} else
{ }
}
2013-11-27 15:48:39 +00:00
/* Look for a JSON request entity */
body = ast_http_get_json ( ser , headers ) ;
if ( ! body ) {
switch ( errno ) {
case EFBIG :
ast_ari_response_error ( response , 413 , " Request Entity Too Large " , " Request body too large " ) ;
goto fin ;
case ENOMEM :
ast_ari_response_error ( response , 500 , " Internal Server Error " , " Error processing request " ) ;
goto fin ;
case EIO :
ast_ari_response_error ( response , 400 , " Bad Request " , " Error parsing request body " ) ;
goto fin ;
}
}
2014-01-21 14:27:21 +00:00
if ( ast_ari_channels_mute_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_channels_mute ( 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 : /* Channel not found */
case 409 : /* Channel not in a Stasis application */
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 /channels/{channelId}/mute \n " , code ) ;
is_valid = 0 ;
}
}
if ( ! is_valid ) {
ast_log ( LOG_ERROR , " Response validation failed for /channels/{channelId}/mute \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_channels_unmute_parse_body (
struct ast_json * body ,
struct ast_ari_channels_unmute_args * args )
{
struct ast_json * field ;
/* Parse query parameters out of it */
field = ast_json_object_get ( body , " direction " ) ;
if ( field ) {
args - > direction = ast_json_string_get ( field ) ;
}
return 0 ;
}
2013-04-22 14:58:53 +00:00
/*!
2013-11-07 21:10:31 +00:00
* \ brief Parameter parsing callback for / channels / { channelId } / mute .
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 .
* \ param [ out ] response Response to the HTTP request .
*/
2013-11-07 21:10:31 +00:00
static void ast_ari_channels_unmute_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 ,
2013-07-27 23:11:02 +00:00
struct ast_variable * headers , struct ast_ari_response * response )
2013-04-22 14:58:53 +00:00
{
2013-11-07 21:10:31 +00:00
struct ast_ari_channels_unmute_args args = { } ;
2013-08-02 14:36:32 +00:00
struct ast_variable * i ;
2013-11-27 15:48:39 +00:00
RAII_VAR ( struct ast_json * , body , NULL , ast_json_unref ) ;
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 , " direction " ) = = 0 ) {
args . direction = ( i - > value ) ;
} else
{ }
}
for ( i = path_vars ; i ; i = i - > next ) {
if ( strcmp ( i - > name , " channelId " ) = = 0 ) {
args . channel_id = ( i - > value ) ;
} else
{ }
}
2013-11-27 15:48:39 +00:00
/* Look for a JSON request entity */
body = ast_http_get_json ( ser , headers ) ;
if ( ! body ) {
switch ( errno ) {
case EFBIG :
ast_ari_response_error ( response , 413 , " Request Entity Too Large " , " Request body too large " ) ;
goto fin ;
case ENOMEM :
ast_ari_response_error ( response , 500 , " Internal Server Error " , " Error processing request " ) ;
goto fin ;
case EIO :
ast_ari_response_error ( response , 400 , " Bad Request " , " Error parsing request body " ) ;
goto fin ;
}
}
2014-01-21 14:27:21 +00:00
if ( ast_ari_channels_unmute_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_channels_unmute ( 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 : /* Channel not found */
case 409 : /* Channel not in a Stasis application */
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 {
2013-11-07 21:10:31 +00:00
ast_log ( LOG_ERROR , " Invalid error response %d for /channels/{channelId}/mute \n " , code ) ;
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 = 0 ;
}
}
if ( ! is_valid ) {
2013-11-07 21:10:31 +00:00
ast_log ( LOG_ERROR , " Response validation failed for /channels/{channelId}/mute \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 / channels / { channelId } / hold .
* \ param get_params GET parameters in the HTTP request .
* \ param path_vars Path variables extracted from the request .
* \ param headers HTTP headers .
* \ param [ out ] response Response to the HTTP request .
*/
2013-11-07 21:10:31 +00:00
static void ast_ari_channels_hold_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 ,
2013-07-27 23:11:02 +00:00
struct ast_variable * headers , struct ast_ari_response * response )
2013-04-22 14:58:53 +00:00
{
2013-11-07 21:10:31 +00:00
struct ast_ari_channels_hold_args args = { } ;
2013-08-02 14:36:32 +00:00
struct ast_variable * i ;
2013-11-27 15:48:39 +00:00
RAII_VAR ( struct ast_json * , body , NULL , ast_json_unref ) ;
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 , " channelId " ) = = 0 ) {
args . channel_id = ( i - > value ) ;
} else
{ }
}
2013-11-07 21:10:31 +00:00
ast_ari_channels_hold ( 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 : /* Channel not found */
case 409 : /* Channel not in a Stasis application */
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 /channels/{channelId}/hold \n " , code ) ;
is_valid = 0 ;
}
}
if ( ! is_valid ) {
ast_log ( LOG_ERROR , " Response validation failed for /channels/{channelId}/hold \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
}
/*!
2013-10-15 15:30:39 +00:00
* \ brief Parameter parsing callback for / channels / { channelId } / hold .
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 .
* \ param [ out ] response Response to the HTTP request .
*/
2013-11-07 21:10:31 +00:00
static void ast_ari_channels_unhold_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 ,
2013-07-27 23:11:02 +00:00
struct ast_variable * headers , struct ast_ari_response * response )
2013-04-22 14:58:53 +00:00
{
2013-11-07 21:10:31 +00:00
struct ast_ari_channels_unhold_args args = { } ;
2013-08-02 14:36:32 +00:00
struct ast_variable * i ;
2013-11-27 15:48:39 +00:00
RAII_VAR ( struct ast_json * , body , NULL , ast_json_unref ) ;
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 , " channelId " ) = = 0 ) {
args . channel_id = ( i - > value ) ;
} else
{ }
}
2013-11-07 21:10:31 +00:00
ast_ari_channels_unhold ( 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 : /* Channel not found */
case 409 : /* Channel not in a Stasis application */
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 {
2013-10-15 15:30:39 +00:00
ast_log ( LOG_ERROR , " Invalid error response %d for /channels/{channelId}/hold \n " , code ) ;
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 = 0 ;
}
}
if ( ! is_valid ) {
2013-10-15 15:30:39 +00:00
ast_log ( LOG_ERROR , " Response validation failed for /channels/{channelId}/hold \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_channels_start_moh_parse_body (
struct ast_json * body ,
struct ast_ari_channels_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-07-19 19:40:27 +00:00
/*!
2013-10-15 15:30:39 +00:00
* \ brief Parameter parsing callback for / channels / { channelId } / moh .
2013-07-19 19:40:27 +00:00
* \ param get_params GET parameters in the HTTP request .
* \ param path_vars Path variables extracted from the request .
* \ param headers HTTP headers .
* \ param [ out ] response Response to the HTTP request .
*/
2013-11-07 21:10:31 +00:00
static void ast_ari_channels_start_moh_cb (
2013-11-27 15:48:39 +00:00
struct ast_tcptls_session_instance * ser ,
2013-07-19 19:40:27 +00:00
struct ast_variable * get_params , struct ast_variable * path_vars ,
2013-07-27 23:11:02 +00:00
struct ast_variable * headers , struct ast_ari_response * response )
2013-07-19 19:40:27 +00:00
{
2013-11-07 21:10:31 +00:00
struct ast_ari_channels_start_moh_args args = { } ;
2013-08-02 14:36:32 +00:00
struct ast_variable * i ;
2013-11-27 15:48:39 +00:00
RAII_VAR ( struct ast_json * , body , NULL , ast_json_unref ) ;
2013-07-19 19:40:27 +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 , " mohClass " ) = = 0 ) {
args . moh_class = ( i - > value ) ;
} else
{ }
}
for ( i = path_vars ; i ; i = i - > next ) {
if ( strcmp ( i - > name , " channelId " ) = = 0 ) {
args . channel_id = ( i - > value ) ;
} else
{ }
}
2013-11-27 15:48:39 +00:00
/* Look for a JSON request entity */
body = ast_http_get_json ( ser , headers ) ;
if ( ! body ) {
switch ( errno ) {
case EFBIG :
ast_ari_response_error ( response , 413 , " Request Entity Too Large " , " Request body too large " ) ;
goto fin ;
case ENOMEM :
ast_ari_response_error ( response , 500 , " Internal Server Error " , " Error processing request " ) ;
goto fin ;
case EIO :
ast_ari_response_error ( response , 400 , " Bad Request " , " Error parsing request body " ) ;
goto fin ;
}
}
2014-01-21 14:27:21 +00:00
if ( ast_ari_channels_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_channels_start_moh ( headers , & args , response ) ;
2013-07-19 19:40:27 +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:40:27 +00:00
case 404 : /* Channel not found */
case 409 : /* Channel not in a Stasis application */
is_valid = 1 ;
break ;
default :
if ( 200 < = code & & code < = 299 ) {
2013-07-27 23:11:02 +00:00
is_valid = ast_ari_validate_void (
2013-07-19 19:40:27 +00:00
response - > message ) ;
} else {
2013-10-15 15:30:39 +00:00
ast_log ( LOG_ERROR , " Invalid error response %d for /channels/{channelId}/moh \n " , code ) ;
2013-07-19 19:40:27 +00:00
is_valid = 0 ;
}
}
if ( ! is_valid ) {
2013-10-15 15:30:39 +00:00
ast_log ( LOG_ERROR , " Response validation failed for /channels/{channelId}/moh \n " ) ;
2013-07-27 23:11:02 +00:00
ast_ari_response_error ( response , 500 ,
2013-07-19 19:40:27 +00:00
" Internal Server Error " , " Response validation failed " ) ;
}
# endif /* AST_DEVMODE */
2013-08-02 14:36:32 +00:00
fin : __attribute__ ( ( unused ) )
return ;
2013-07-19 19:40:27 +00:00
}
/*!
2013-10-15 15:30:39 +00:00
* \ brief Parameter parsing callback for / channels / { channelId } / moh .
2013-07-19 19:40:27 +00:00
* \ param get_params GET parameters in the HTTP request .
* \ param path_vars Path variables extracted from the request .
* \ param headers HTTP headers .
* \ param [ out ] response Response to the HTTP request .
*/
2013-11-07 21:10:31 +00:00
static void ast_ari_channels_stop_moh_cb (
2013-11-27 15:48:39 +00:00
struct ast_tcptls_session_instance * ser ,
2013-07-19 19:40:27 +00:00
struct ast_variable * get_params , struct ast_variable * path_vars ,
2013-07-27 23:11:02 +00:00
struct ast_variable * headers , struct ast_ari_response * response )
2013-07-19 19:40:27 +00:00
{
2013-11-07 21:10:31 +00:00
struct ast_ari_channels_stop_moh_args args = { } ;
2013-08-02 14:36:32 +00:00
struct ast_variable * i ;
2013-11-27 15:48:39 +00:00
RAII_VAR ( struct ast_json * , body , NULL , ast_json_unref ) ;
2013-07-19 19:40:27 +00:00
# if defined(AST_DEVMODE)
int is_valid ;
int code ;
# endif /* AST_DEVMODE */
for ( i = path_vars ; i ; i = i - > next ) {
if ( strcmp ( i - > name , " channelId " ) = = 0 ) {
args . channel_id = ( i - > value ) ;
} else
{ }
}
2013-11-07 21:10:31 +00:00
ast_ari_channels_stop_moh ( headers , & args , response ) ;
2013-07-19 19:40:27 +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:40:27 +00:00
case 404 : /* Channel not found */
case 409 : /* Channel not in a Stasis application */
is_valid = 1 ;
break ;
default :
if ( 200 < = code & & code < = 299 ) {
2013-07-27 23:11:02 +00:00
is_valid = ast_ari_validate_void (
2013-07-19 19:40:27 +00:00
response - > message ) ;
} else {
2013-10-15 15:30:39 +00:00
ast_log ( LOG_ERROR , " Invalid error response %d for /channels/{channelId}/moh \n " , code ) ;
2013-07-19 19:40:27 +00:00
is_valid = 0 ;
}
}
if ( ! is_valid ) {
2013-10-15 15:30:39 +00:00
ast_log ( LOG_ERROR , " Response validation failed for /channels/{channelId}/moh \n " ) ;
2013-07-27 23:11:02 +00:00
ast_ari_response_error ( response , 500 ,
2013-07-19 19:40:27 +00:00
" Internal Server Error " , " Response validation failed " ) ;
}
# endif /* AST_DEVMODE */
2013-08-02 14:36:32 +00:00
2013-11-21 15:56:34 +00:00
fin : __attribute__ ( ( unused ) )
return ;
}
/*!
* \ brief Parameter parsing callback for / channels / { channelId } / silence .
* \ param get_params GET parameters in the HTTP request .
* \ param path_vars Path variables extracted from the request .
* \ param headers HTTP headers .
* \ param [ out ] response Response to the HTTP request .
*/
static void ast_ari_channels_start_silence_cb (
2013-11-27 15:48:39 +00:00
struct ast_tcptls_session_instance * ser ,
2013-11-21 15:56:34 +00:00
struct ast_variable * get_params , struct ast_variable * path_vars ,
struct ast_variable * headers , struct ast_ari_response * response )
{
struct ast_ari_channels_start_silence_args args = { } ;
struct ast_variable * i ;
2013-11-27 15:48:39 +00:00
RAII_VAR ( struct ast_json * , body , NULL , ast_json_unref ) ;
2013-11-21 15:56:34 +00:00
# if defined(AST_DEVMODE)
int is_valid ;
int code ;
# endif /* AST_DEVMODE */
for ( i = path_vars ; i ; i = i - > next ) {
if ( strcmp ( i - > name , " channelId " ) = = 0 ) {
args . channel_id = ( i - > value ) ;
} else
{ }
}
ast_ari_channels_start_silence ( 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 : /* Channel not found */
case 409 : /* Channel not in a Stasis application */
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 /channels/{channelId}/silence \n " , code ) ;
is_valid = 0 ;
}
}
if ( ! is_valid ) {
ast_log ( LOG_ERROR , " Response validation failed for /channels/{channelId}/silence \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 / channels / { channelId } / silence .
* \ param get_params GET parameters in the HTTP request .
* \ param path_vars Path variables extracted from the request .
* \ param headers HTTP headers .
* \ param [ out ] response Response to the HTTP request .
*/
static void ast_ari_channels_stop_silence_cb (
2013-11-27 15:48:39 +00:00
struct ast_tcptls_session_instance * ser ,
2013-11-21 15:56:34 +00:00
struct ast_variable * get_params , struct ast_variable * path_vars ,
struct ast_variable * headers , struct ast_ari_response * response )
{
struct ast_ari_channels_stop_silence_args args = { } ;
struct ast_variable * i ;
2013-11-27 15:48:39 +00:00
RAII_VAR ( struct ast_json * , body , NULL , ast_json_unref ) ;
2013-11-21 15:56:34 +00:00
# if defined(AST_DEVMODE)
int is_valid ;
int code ;
# endif /* AST_DEVMODE */
for ( i = path_vars ; i ; i = i - > next ) {
if ( strcmp ( i - > name , " channelId " ) = = 0 ) {
args . channel_id = ( i - > value ) ;
} else
{ }
}
ast_ari_channels_stop_silence ( 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 : /* Channel not found */
case 409 : /* Channel not in a Stasis application */
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 /channels/{channelId}/silence \n " , code ) ;
is_valid = 0 ;
}
}
if ( ! is_valid ) {
ast_log ( LOG_ERROR , " Response validation failed for /channels/{channelId}/silence \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-07-19 19:40:27 +00:00
}
2014-01-21 14:27:21 +00:00
int ast_ari_channels_play_parse_body (
struct ast_json * body ,
struct ast_ari_channels_play_args * args )
{
struct ast_json * field ;
/* Parse query parameters out of it */
field = ast_json_object_get ( body , " media " ) ;
if ( field ) {
args - > media = ast_json_string_get ( field ) ;
}
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 ) ;
}
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 , " playbackId " ) ;
if ( field ) {
args - > playback_id = ast_json_string_get ( field ) ;
}
2014-01-21 14:27:21 +00:00
return 0 ;
}
2013-04-22 14:58:53 +00:00
/*!
* \ brief Parameter parsing callback for / channels / { channelId } / play .
* \ param get_params GET parameters in the HTTP request .
* \ param path_vars Path variables extracted from the request .
* \ param headers HTTP headers .
* \ param [ out ] response Response to the HTTP request .
*/
2013-11-07 21:10:31 +00:00
static void ast_ari_channels_play_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 ,
2013-07-27 23:11:02 +00:00
struct ast_variable * headers , struct ast_ari_response * response )
2013-04-22 14:58:53 +00:00
{
2013-11-07 21:10:31 +00:00
struct ast_ari_channels_play_args args = { } ;
2013-08-02 14:36:32 +00:00
struct ast_variable * i ;
2013-11-27 15:48:39 +00:00
RAII_VAR ( struct ast_json * , body , NULL , ast_json_unref ) ;
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 , " media " ) = = 0 ) {
args . media = ( i - > value ) ;
} else
2013-05-23 20:11:35 +00:00
if ( strcmp ( i - > name , " lang " ) = = 0 ) {
args . lang = ( i - > value ) ;
} else
2013-05-23 20:21:16 +00:00
if ( strcmp ( i - > name , " offsetms " ) = = 0 ) {
args . offsetms = atoi ( i - > value ) ;
} else
if ( strcmp ( i - > name , " skipms " ) = = 0 ) {
args . skipms = atoi ( 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 , " playbackId " ) = = 0 ) {
args . playback_id = ( i - > value ) ;
} else
2013-04-22 14:58:53 +00:00
{ }
}
for ( i = path_vars ; i ; i = i - > next ) {
if ( strcmp ( i - > name , " channelId " ) = = 0 ) {
args . channel_id = ( i - > value ) ;
} else
{ }
}
2013-11-27 15:48:39 +00:00
/* Look for a JSON request entity */
body = ast_http_get_json ( ser , headers ) ;
if ( ! body ) {
switch ( errno ) {
case EFBIG :
ast_ari_response_error ( response , 413 , " Request Entity Too Large " , " Request body too large " ) ;
goto fin ;
case ENOMEM :
ast_ari_response_error ( response , 500 , " Internal Server Error " , " Error processing request " ) ;
goto fin ;
case EIO :
ast_ari_response_error ( response , 400 , " Bad Request " , " Error parsing request body " ) ;
goto fin ;
}
}
2014-01-21 14:27:21 +00:00
if ( ast_ari_channels_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_channels_play ( 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 : /* Channel not found */
case 409 : /* Channel not in a Stasis application */
is_valid = 1 ;
break ;
default :
if ( 200 < = code & & code < = 299 ) {
2013-07-27 23:11:02 +00:00
is_valid = ast_ari_validate_playback (
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 /channels/{channelId}/play \n " , code ) ;
is_valid = 0 ;
}
}
if ( ! is_valid ) {
ast_log ( LOG_ERROR , " Response validation failed for /channels/{channelId}/play \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 ;
}
int ast_ari_channels_play_with_id_parse_body (
struct ast_json * body ,
struct ast_ari_channels_play_with_id_args * args )
{
struct ast_json * field ;
/* Parse query parameters out of it */
field = ast_json_object_get ( body , " media " ) ;
if ( field ) {
args - > media = ast_json_string_get ( field ) ;
}
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 / channels / { channelId } / play / { playbackId } .
* \ param get_params GET parameters in the HTTP request .
* \ param path_vars Path variables extracted from the request .
* \ param headers HTTP headers .
* \ param [ out ] response Response to the HTTP request .
*/
static void ast_ari_channels_play_with_id_cb (
struct ast_tcptls_session_instance * ser ,
struct ast_variable * get_params , struct ast_variable * path_vars ,
struct ast_variable * headers , struct ast_ari_response * response )
{
struct ast_ari_channels_play_with_id_args args = { } ;
struct ast_variable * i ;
RAII_VAR ( struct ast_json * , body , NULL , ast_json_unref ) ;
# 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 ) {
args . media = ( i - > value ) ;
} else
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 , " channelId " ) = = 0 ) {
args . channel_id = ( i - > value ) ;
} else
if ( strcmp ( i - > name , " playbackId " ) = = 0 ) {
args . playback_id = ( i - > value ) ;
} else
{ }
}
/* Look for a JSON request entity */
body = ast_http_get_json ( ser , headers ) ;
if ( ! body ) {
switch ( errno ) {
case EFBIG :
ast_ari_response_error ( response , 413 , " Request Entity Too Large " , " Request body too large " ) ;
goto fin ;
case ENOMEM :
ast_ari_response_error ( response , 500 , " Internal Server Error " , " Error processing request " ) ;
goto fin ;
case EIO :
ast_ari_response_error ( response , 400 , " Bad Request " , " Error parsing request body " ) ;
goto fin ;
}
}
if ( ast_ari_channels_play_with_id_parse_body ( body , & args ) ) {
ast_ari_response_alloc_failed ( response ) ;
goto fin ;
}
ast_ari_channels_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 : /* Channel not found */
case 409 : /* Channel not in a Stasis application */
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 /channels/{channelId}/play/{playbackId} \n " , code ) ;
is_valid = 0 ;
}
}
if ( ! is_valid ) {
ast_log ( LOG_ERROR , " Response validation failed for /channels/{channelId}/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 ) )
return ;
2013-04-22 14:58:53 +00:00
}
2014-01-21 14:27:21 +00:00
int ast_ari_channels_record_parse_body (
struct ast_json * body ,
struct ast_ari_channels_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 ) ;
}
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 / channels / { channelId } / record .
* \ param get_params GET parameters in the HTTP request .
* \ param path_vars Path variables extracted from the request .
* \ param headers HTTP headers .
* \ param [ out ] response Response to the HTTP request .
*/
2013-11-07 21:10:31 +00:00
static void ast_ari_channels_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 ,
2013-07-27 23:11:02 +00:00
struct ast_variable * headers , struct ast_ari_response * response )
2013-04-22 14:58:53 +00:00
{
2013-11-07 21:10:31 +00:00
struct ast_ari_channels_record_args args = { } ;
2013-08-02 14:36:32 +00:00
struct ast_variable * i ;
2013-11-27 15:48:39 +00:00
RAII_VAR ( struct ast_json * , body , NULL , ast_json_unref ) ;
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
if ( strcmp ( i - > name , " format " ) = = 0 ) {
args . format = ( i - > value ) ;
} else
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-03 17:58:45 +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 , " channelId " ) = = 0 ) {
args . channel_id = ( i - > value ) ;
} else
{ }
}
2013-11-27 15:48:39 +00:00
/* Look for a JSON request entity */
body = ast_http_get_json ( ser , headers ) ;
if ( ! body ) {
switch ( errno ) {
case EFBIG :
ast_ari_response_error ( response , 413 , " Request Entity Too Large " , " Request body too large " ) ;
goto fin ;
case ENOMEM :
ast_ari_response_error ( response , 500 , " Internal Server Error " , " Error processing request " ) ;
goto fin ;
case EIO :
ast_ari_response_error ( response , 400 , " Bad Request " , " Error parsing request body " ) ;
goto fin ;
}
}
2014-01-21 14:27:21 +00:00
if ( ast_ari_channels_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_channels_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-07-03 17:58:45 +00:00
case 400 : /* Invalid parameters */
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 : /* Channel not found */
2013-10-25 21:28:32 +00:00
case 409 : /* Channel is not in a Stasis application; the channel is currently bridged with other hcannels; 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 /channels/{channelId}/record \n " , code ) ;
is_valid = 0 ;
}
}
if ( ! is_valid ) {
ast_log ( LOG_ERROR , " Response validation failed for /channels/{channelId}/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
}
2014-01-21 14:27:21 +00:00
int ast_ari_channels_get_channel_var_parse_body (
struct ast_json * body ,
struct ast_ari_channels_get_channel_var_args * args )
{
struct ast_json * field ;
/* Parse query parameters out of it */
field = ast_json_object_get ( body , " variable " ) ;
if ( field ) {
args - > variable = ast_json_string_get ( field ) ;
}
return 0 ;
}
2013-07-08 14:46:20 +00:00
/*!
* \ brief Parameter parsing callback for / channels / { channelId } / variable .
* \ param get_params GET parameters in the HTTP request .
* \ param path_vars Path variables extracted from the request .
* \ param headers HTTP headers .
* \ param [ out ] response Response to the HTTP request .
*/
2013-11-07 21:10:31 +00:00
static void ast_ari_channels_get_channel_var_cb (
2013-11-27 15:48:39 +00:00
struct ast_tcptls_session_instance * ser ,
2013-07-10 13:50:48 +00:00
struct ast_variable * get_params , struct ast_variable * path_vars ,
2013-07-27 23:11:02 +00:00
struct ast_variable * headers , struct ast_ari_response * response )
2013-07-08 14:46:20 +00:00
{
2013-11-07 21:10:31 +00:00
struct ast_ari_channels_get_channel_var_args args = { } ;
2013-08-02 14:36:32 +00:00
struct ast_variable * i ;
2013-11-27 15:48:39 +00:00
RAII_VAR ( struct ast_json * , body , NULL , ast_json_unref ) ;
2013-07-10 13:50:48 +00:00
# if defined(AST_DEVMODE)
int is_valid ;
int code ;
# endif /* AST_DEVMODE */
2013-07-08 14:46:20 +00:00
for ( i = get_params ; i ; i = i - > next ) {
if ( strcmp ( i - > name , " variable " ) = = 0 ) {
args . variable = ( i - > value ) ;
} else
{ }
}
for ( i = path_vars ; i ; i = i - > next ) {
if ( strcmp ( i - > name , " channelId " ) = = 0 ) {
args . channel_id = ( i - > value ) ;
} else
{ }
}
2013-11-27 15:48:39 +00:00
/* Look for a JSON request entity */
body = ast_http_get_json ( ser , headers ) ;
if ( ! body ) {
switch ( errno ) {
case EFBIG :
ast_ari_response_error ( response , 413 , " Request Entity Too Large " , " Request body too large " ) ;
goto fin ;
case ENOMEM :
ast_ari_response_error ( response , 500 , " Internal Server Error " , " Error processing request " ) ;
goto fin ;
case EIO :
ast_ari_response_error ( response , 400 , " Bad Request " , " Error parsing request body " ) ;
goto fin ;
}
}
2014-01-21 14:27:21 +00:00
if ( ast_ari_channels_get_channel_var_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_channels_get_channel_var ( headers , & args , response ) ;
2013-07-10 13:50:48 +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-21 16:23:59 +00:00
case 400 : /* Missing variable parameter. */
2015-02-21 20:48:17 +00:00
case 404 : /* Channel or variable not found */
2013-07-10 13:50:48 +00:00
case 409 : /* Channel not in a Stasis application */
is_valid = 1 ;
break ;
default :
if ( 200 < = code & & code < = 299 ) {
2013-07-27 23:11:02 +00:00
is_valid = ast_ari_validate_variable (
2013-07-10 13:50:48 +00:00
response - > message ) ;
} else {
ast_log ( LOG_ERROR , " Invalid error response %d for /channels/{channelId}/variable \n " , code ) ;
is_valid = 0 ;
}
}
if ( ! is_valid ) {
ast_log ( LOG_ERROR , " Response validation failed for /channels/{channelId}/variable \n " ) ;
2013-07-27 23:11:02 +00:00
ast_ari_response_error ( response , 500 ,
2013-07-10 13:50:48 +00:00
" Internal Server Error " , " Response validation failed " ) ;
}
# endif /* AST_DEVMODE */
2013-08-02 14:36:32 +00:00
fin : __attribute__ ( ( unused ) )
return ;
2013-07-08 14:46:20 +00:00
}
2014-01-21 14:27:21 +00:00
int ast_ari_channels_set_channel_var_parse_body (
struct ast_json * body ,
struct ast_ari_channels_set_channel_var_args * args )
{
struct ast_json * field ;
/* Parse query parameters out of it */
field = ast_json_object_get ( body , " variable " ) ;
if ( field ) {
args - > variable = ast_json_string_get ( field ) ;
}
field = ast_json_object_get ( body , " value " ) ;
if ( field ) {
args - > value = ast_json_string_get ( field ) ;
}
return 0 ;
}
2013-07-08 14:46:20 +00:00
/*!
* \ brief Parameter parsing callback for / channels / { channelId } / variable .
* \ param get_params GET parameters in the HTTP request .
* \ param path_vars Path variables extracted from the request .
* \ param headers HTTP headers .
* \ param [ out ] response Response to the HTTP request .
*/
2013-11-07 21:10:31 +00:00
static void ast_ari_channels_set_channel_var_cb (
2013-11-27 15:48:39 +00:00
struct ast_tcptls_session_instance * ser ,
2013-07-10 13:50:48 +00:00
struct ast_variable * get_params , struct ast_variable * path_vars ,
2013-07-27 23:11:02 +00:00
struct ast_variable * headers , struct ast_ari_response * response )
2013-07-08 14:46:20 +00:00
{
2013-11-07 21:10:31 +00:00
struct ast_ari_channels_set_channel_var_args args = { } ;
2013-08-02 14:36:32 +00:00
struct ast_variable * i ;
2013-11-27 15:48:39 +00:00
RAII_VAR ( struct ast_json * , body , NULL , ast_json_unref ) ;
2013-07-10 13:50:48 +00:00
# if defined(AST_DEVMODE)
int is_valid ;
int code ;
# endif /* AST_DEVMODE */
2013-07-08 14:46:20 +00:00
for ( i = get_params ; i ; i = i - > next ) {
if ( strcmp ( i - > name , " variable " ) = = 0 ) {
args . variable = ( i - > value ) ;
} else
if ( strcmp ( i - > name , " value " ) = = 0 ) {
args . value = ( i - > value ) ;
} else
{ }
}
for ( i = path_vars ; i ; i = i - > next ) {
if ( strcmp ( i - > name , " channelId " ) = = 0 ) {
args . channel_id = ( i - > value ) ;
} else
{ }
}
2013-11-27 15:48:39 +00:00
/* Look for a JSON request entity */
body = ast_http_get_json ( ser , headers ) ;
if ( ! body ) {
switch ( errno ) {
case EFBIG :
ast_ari_response_error ( response , 413 , " Request Entity Too Large " , " Request body too large " ) ;
goto fin ;
case ENOMEM :
ast_ari_response_error ( response , 500 , " Internal Server Error " , " Error processing request " ) ;
goto fin ;
case EIO :
ast_ari_response_error ( response , 400 , " Bad Request " , " Error parsing request body " ) ;
goto fin ;
}
}
2014-01-21 14:27:21 +00:00
if ( ast_ari_channels_set_channel_var_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_channels_set_channel_var ( headers , & args , response ) ;
2013-07-10 13:50:48 +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-21 16:23:59 +00:00
case 400 : /* Missing variable parameter. */
2013-07-10 13:50:48 +00:00
case 404 : /* Channel not found */
case 409 : /* Channel not in a Stasis application */
is_valid = 1 ;
break ;
default :
if ( 200 < = code & & code < = 299 ) {
2013-07-27 23:11:02 +00:00
is_valid = ast_ari_validate_void (
2013-07-10 13:50:48 +00:00
response - > message ) ;
} else {
ast_log ( LOG_ERROR , " Invalid error response %d for /channels/{channelId}/variable \n " , code ) ;
is_valid = 0 ;
}
}
if ( ! is_valid ) {
ast_log ( LOG_ERROR , " Response validation failed for /channels/{channelId}/variable \n " ) ;
2013-07-27 23:11:02 +00:00
ast_ari_response_error ( response , 500 ,
2013-07-10 13:50:48 +00:00
" Internal Server Error " , " Response validation failed " ) ;
}
# endif /* AST_DEVMODE */
2013-08-02 14:36:32 +00:00
2013-11-23 12:40:46 +00:00
fin : __attribute__ ( ( unused ) )
return ;
}
2014-01-21 14:27:21 +00:00
int ast_ari_channels_snoop_channel_parse_body (
struct ast_json * body ,
struct ast_ari_channels_snoop_channel_args * args )
{
struct ast_json * field ;
/* Parse query parameters out of it */
field = ast_json_object_get ( body , " spy " ) ;
if ( field ) {
args - > spy = ast_json_string_get ( field ) ;
}
field = ast_json_object_get ( body , " whisper " ) ;
if ( field ) {
args - > whisper = ast_json_string_get ( field ) ;
}
field = ast_json_object_get ( body , " app " ) ;
if ( field ) {
args - > app = ast_json_string_get ( field ) ;
}
field = ast_json_object_get ( body , " appArgs " ) ;
if ( field ) {
args - > app_args = 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 , " snoopId " ) ;
if ( field ) {
args - > snoop_id = ast_json_string_get ( field ) ;
}
2014-01-21 14:27:21 +00:00
return 0 ;
}
2013-11-23 12:40:46 +00:00
/*!
* \ brief Parameter parsing callback for / channels / { channelId } / snoop .
* \ param get_params GET parameters in the HTTP request .
* \ param path_vars Path variables extracted from the request .
* \ param headers HTTP headers .
* \ param [ out ] response Response to the HTTP request .
*/
static void ast_ari_channels_snoop_channel_cb (
2013-11-27 15:48:39 +00:00
struct ast_tcptls_session_instance * ser ,
2013-11-23 12:40:46 +00:00
struct ast_variable * get_params , struct ast_variable * path_vars ,
struct ast_variable * headers , struct ast_ari_response * response )
{
struct ast_ari_channels_snoop_channel_args args = { } ;
struct ast_variable * i ;
2013-11-27 15:48:39 +00:00
RAII_VAR ( struct ast_json * , body , NULL , ast_json_unref ) ;
2013-11-23 12:40:46 +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 , " spy " ) = = 0 ) {
args . spy = ( i - > value ) ;
} else
if ( strcmp ( i - > name , " whisper " ) = = 0 ) {
args . whisper = ( i - > value ) ;
} else
if ( strcmp ( i - > name , " app " ) = = 0 ) {
args . app = ( i - > value ) ;
} else
if ( strcmp ( i - > name , " appArgs " ) = = 0 ) {
args . app_args = ( 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 , " snoopId " ) = = 0 ) {
args . snoop_id = ( i - > value ) ;
} else
2013-11-23 12:40:46 +00:00
{ }
}
for ( i = path_vars ; i ; i = i - > next ) {
if ( strcmp ( i - > name , " channelId " ) = = 0 ) {
args . channel_id = ( i - > value ) ;
} else
{ }
}
2013-11-27 15:48:39 +00:00
/* Look for a JSON request entity */
body = ast_http_get_json ( ser , headers ) ;
if ( ! body ) {
switch ( errno ) {
case EFBIG :
ast_ari_response_error ( response , 413 , " Request Entity Too Large " , " Request body too large " ) ;
goto fin ;
case ENOMEM :
ast_ari_response_error ( response , 500 , " Internal Server Error " , " Error processing request " ) ;
goto fin ;
case EIO :
ast_ari_response_error ( response , 400 , " Bad Request " , " Error parsing request body " ) ;
goto fin ;
}
}
2014-01-21 14:27:21 +00:00
if ( ast_ari_channels_snoop_channel_parse_body ( body , & args ) ) {
ast_ari_response_alloc_failed ( response ) ;
goto fin ;
2013-11-27 15:48:39 +00:00
}
2013-11-23 12:40:46 +00:00
ast_ari_channels_snoop_channel ( 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 400 : /* Invalid parameters */
case 404 : /* Channel not found */
is_valid = 1 ;
break ;
default :
if ( 200 < = code & & code < = 299 ) {
is_valid = ast_ari_validate_channel (
response - > message ) ;
} else {
ast_log ( LOG_ERROR , " Invalid error response %d for /channels/{channelId}/snoop \n " , code ) ;
is_valid = 0 ;
}
}
if ( ! is_valid ) {
ast_log ( LOG_ERROR , " Response validation failed for /channels/{channelId}/snoop \n " ) ;
ast_ari_response_error ( response , 500 ,
" Internal Server Error " , " Response validation failed " ) ;
}
# endif /* AST_DEVMODE */
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 ;
}
int ast_ari_channels_snoop_channel_with_id_parse_body (
struct ast_json * body ,
struct ast_ari_channels_snoop_channel_with_id_args * args )
{
struct ast_json * field ;
/* Parse query parameters out of it */
field = ast_json_object_get ( body , " spy " ) ;
if ( field ) {
args - > spy = ast_json_string_get ( field ) ;
}
field = ast_json_object_get ( body , " whisper " ) ;
if ( field ) {
args - > whisper = ast_json_string_get ( field ) ;
}
field = ast_json_object_get ( body , " app " ) ;
if ( field ) {
args - > app = ast_json_string_get ( field ) ;
}
field = ast_json_object_get ( body , " appArgs " ) ;
if ( field ) {
args - > app_args = ast_json_string_get ( field ) ;
}
return 0 ;
}
/*!
* \ brief Parameter parsing callback for / channels / { channelId } / snoop / { snoopId } .
* \ param get_params GET parameters in the HTTP request .
* \ param path_vars Path variables extracted from the request .
* \ param headers HTTP headers .
* \ param [ out ] response Response to the HTTP request .
*/
static void ast_ari_channels_snoop_channel_with_id_cb (
struct ast_tcptls_session_instance * ser ,
struct ast_variable * get_params , struct ast_variable * path_vars ,
struct ast_variable * headers , struct ast_ari_response * response )
{
struct ast_ari_channels_snoop_channel_with_id_args args = { } ;
struct ast_variable * i ;
RAII_VAR ( struct ast_json * , body , NULL , ast_json_unref ) ;
# if defined(AST_DEVMODE)
int is_valid ;
int code ;
# endif /* AST_DEVMODE */
for ( i = get_params ; i ; i = i - > next ) {
if ( strcmp ( i - > name , " spy " ) = = 0 ) {
args . spy = ( i - > value ) ;
} else
if ( strcmp ( i - > name , " whisper " ) = = 0 ) {
args . whisper = ( i - > value ) ;
} else
if ( strcmp ( i - > name , " app " ) = = 0 ) {
args . app = ( i - > value ) ;
} else
if ( strcmp ( i - > name , " appArgs " ) = = 0 ) {
args . app_args = ( i - > value ) ;
} else
{ }
}
for ( i = path_vars ; i ; i = i - > next ) {
if ( strcmp ( i - > name , " channelId " ) = = 0 ) {
args . channel_id = ( i - > value ) ;
} else
if ( strcmp ( i - > name , " snoopId " ) = = 0 ) {
args . snoop_id = ( i - > value ) ;
} else
{ }
}
/* Look for a JSON request entity */
body = ast_http_get_json ( ser , headers ) ;
if ( ! body ) {
switch ( errno ) {
case EFBIG :
ast_ari_response_error ( response , 413 , " Request Entity Too Large " , " Request body too large " ) ;
goto fin ;
case ENOMEM :
ast_ari_response_error ( response , 500 , " Internal Server Error " , " Error processing request " ) ;
goto fin ;
case EIO :
ast_ari_response_error ( response , 400 , " Bad Request " , " Error parsing request body " ) ;
goto fin ;
}
}
if ( ast_ari_channels_snoop_channel_with_id_parse_body ( body , & args ) ) {
ast_ari_response_alloc_failed ( response ) ;
goto fin ;
}
ast_ari_channels_snoop_channel_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 400 : /* Invalid parameters */
case 404 : /* Channel not found */
is_valid = 1 ;
break ;
default :
if ( 200 < = code & & code < = 299 ) {
is_valid = ast_ari_validate_channel (
response - > message ) ;
} else {
ast_log ( LOG_ERROR , " Invalid error response %d for /channels/{channelId}/snoop/{snoopId} \n " , code ) ;
is_valid = 0 ;
}
}
if ( ! is_valid ) {
ast_log ( LOG_ERROR , " Response validation failed for /channels/{channelId}/snoop/{snoopId} \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-07-08 14:46:20 +00:00
}
2013-04-22 14:58:53 +00:00
/*! \brief REST handler for /api-docs/channels.{format} */
static struct stasis_rest_handlers channels_channelId_continue = {
. path_segment = " continue " ,
. callbacks = {
2013-11-07 21:10:31 +00:00
[ AST_HTTP_POST ] = ast_ari_channels_continue_in_dialplan_cb ,
2013-04-22 14:58:53 +00:00
} ,
. num_children = 0 ,
. children = { }
} ;
/*! \brief REST handler for /api-docs/channels.{format} */
ARI/PJSIP: Add the ability to redirect (transfer) a channel in a Stasis app
This patch adds a new feature to ARI to redirect a channel to another server,
and fixes a few bugs in PJSIP's handling of the Transfer dialplan
application/ARI redirect capability.
*New Feature*
A new operation has been added to the ARI channels resource, redirect. With
this, a channel in a Stasis application can be redirected to another endpoint
of the same underlying channel technology.
*Bug fixes*
In the process of writing this new feature, two bugs were fixed in the PJSIP
stack:
(1) The existing .transfer channel callback had the limitation that it could
only transfer channels to a SIP URI, i.e., you had to pass
'PJSIP/sip:foo@my_provider.com' to the dialplan application. While this is
still supported, it is somewhat unintuitive - particularly in a world full
of endpoints. As such, we now also support specifying the PJSIP endpoint to
transfer to.
(2) res_pjsip_multihomed was, unfortunately, trying to 'help' a 302 redirect by
updating its Contact header. Alas, that resulted in the forwarding
destination set by the dialplan application/ARI resource/whatever being
rewritten with very incorrect information. Hence, we now don't bother
updating an outgoing response if it is a 302. Since this took a looong time
to find, some additional debug statements have been added to those modules
that update the Contact headers.
Review: https://reviewboard.asterisk.org/r/4316/
ASTERISK-24015 #close
Reported by: Private Name
ASTERISK-24703 #close
Reported by: Matt Jordan
........
Merged revisions 431717 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431718 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2015-02-12 20:34:37 +00:00
static struct stasis_rest_handlers channels_channelId_redirect = {
. path_segment = " redirect " ,
. callbacks = {
[ AST_HTTP_POST ] = ast_ari_channels_redirect_cb ,
} ,
. num_children = 0 ,
. children = { }
} ;
/*! \brief REST handler for /api-docs/channels.{format} */
2013-04-22 14:58:53 +00:00
static struct stasis_rest_handlers channels_channelId_answer = {
. path_segment = " answer " ,
. callbacks = {
2013-11-07 21:10:31 +00:00
[ AST_HTTP_POST ] = ast_ari_channels_answer_cb ,
2013-04-22 14:58:53 +00:00
} ,
. num_children = 0 ,
. children = { }
} ;
/*! \brief REST handler for /api-docs/channels.{format} */
2013-11-01 14:38:21 +00:00
static struct stasis_rest_handlers channels_channelId_ring = {
. path_segment = " ring " ,
. callbacks = {
2013-11-07 21:10:31 +00:00
[ AST_HTTP_POST ] = ast_ari_channels_ring_cb ,
2013-11-13 23:11:32 +00:00
[ AST_HTTP_DELETE ] = ast_ari_channels_ring_stop_cb ,
2013-11-01 14:38:21 +00:00
} ,
. num_children = 0 ,
. children = { }
} ;
/*! \brief REST handler for /api-docs/channels.{format} */
static struct stasis_rest_handlers channels_channelId_dtmf = {
. path_segment = " dtmf " ,
. callbacks = {
2013-11-07 21:10:31 +00:00
[ AST_HTTP_POST ] = ast_ari_channels_send_dtmf_cb ,
2013-11-01 14:38:21 +00:00
} ,
. num_children = 0 ,
. children = { }
} ;
/*! \brief REST handler for /api-docs/channels.{format} */
2013-04-22 14:58:53 +00:00
static struct stasis_rest_handlers channels_channelId_mute = {
. path_segment = " mute " ,
. callbacks = {
2013-11-07 21:10:31 +00:00
[ AST_HTTP_POST ] = ast_ari_channels_mute_cb ,
[ AST_HTTP_DELETE ] = ast_ari_channels_unmute_cb ,
2013-04-22 14:58:53 +00:00
} ,
. num_children = 0 ,
. children = { }
} ;
/*! \brief REST handler for /api-docs/channels.{format} */
static struct stasis_rest_handlers channels_channelId_hold = {
. path_segment = " hold " ,
. callbacks = {
2013-11-07 21:10:31 +00:00
[ AST_HTTP_POST ] = ast_ari_channels_hold_cb ,
[ AST_HTTP_DELETE ] = ast_ari_channels_unhold_cb ,
2013-04-22 14:58:53 +00:00
} ,
. num_children = 0 ,
. children = { }
} ;
/*! \brief REST handler for /api-docs/channels.{format} */
2013-10-15 15:30:39 +00:00
static struct stasis_rest_handlers channels_channelId_moh = {
. path_segment = " moh " ,
2013-07-19 19:40:27 +00:00
. callbacks = {
2013-11-07 21:10:31 +00:00
[ AST_HTTP_POST ] = ast_ari_channels_start_moh_cb ,
[ AST_HTTP_DELETE ] = ast_ari_channels_stop_moh_cb ,
2013-07-19 19:40:27 +00:00
} ,
. num_children = 0 ,
. children = { }
} ;
/*! \brief REST handler for /api-docs/channels.{format} */
2013-11-21 15:56:34 +00:00
static struct stasis_rest_handlers channels_channelId_silence = {
. path_segment = " silence " ,
. callbacks = {
[ AST_HTTP_POST ] = ast_ari_channels_start_silence_cb ,
[ AST_HTTP_DELETE ] = ast_ari_channels_stop_silence_cb ,
} ,
. num_children = 0 ,
. children = { }
} ;
/*! \brief REST handler for /api-docs/channels.{format} */
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
static struct stasis_rest_handlers channels_channelId_play_playbackId = {
. path_segment = " playbackId " ,
. is_wildcard = 1 ,
. callbacks = {
[ AST_HTTP_POST ] = ast_ari_channels_play_with_id_cb ,
} ,
. num_children = 0 ,
. children = { }
} ;
/*! \brief REST handler for /api-docs/channels.{format} */
2013-04-22 14:58:53 +00:00
static struct stasis_rest_handlers channels_channelId_play = {
. path_segment = " play " ,
. callbacks = {
2013-11-07 21:10:31 +00:00
[ AST_HTTP_POST ] = ast_ari_channels_play_cb ,
2013-04-22 14:58:53 +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
. num_children = 1 ,
. children = { & channels_channelId_play_playbackId , }
2013-04-22 14:58:53 +00:00
} ;
/*! \brief REST handler for /api-docs/channels.{format} */
static struct stasis_rest_handlers channels_channelId_record = {
. path_segment = " record " ,
. callbacks = {
2013-11-07 21:10:31 +00:00
[ AST_HTTP_POST ] = ast_ari_channels_record_cb ,
2013-04-22 14:58:53 +00:00
} ,
. num_children = 0 ,
. children = { }
} ;
/*! \brief REST handler for /api-docs/channels.{format} */
2013-07-08 14:46:20 +00:00
static struct stasis_rest_handlers channels_channelId_variable = {
. path_segment = " variable " ,
. callbacks = {
2013-11-07 21:10:31 +00:00
[ AST_HTTP_GET ] = ast_ari_channels_get_channel_var_cb ,
[ AST_HTTP_POST ] = ast_ari_channels_set_channel_var_cb ,
2013-07-08 14:46:20 +00:00
} ,
. num_children = 0 ,
. children = { }
} ;
/*! \brief REST handler for /api-docs/channels.{format} */
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
static struct stasis_rest_handlers channels_channelId_snoop_snoopId = {
. path_segment = " snoopId " ,
. is_wildcard = 1 ,
. callbacks = {
[ AST_HTTP_POST ] = ast_ari_channels_snoop_channel_with_id_cb ,
} ,
. num_children = 0 ,
. children = { }
} ;
/*! \brief REST handler for /api-docs/channels.{format} */
2013-11-23 12:40:46 +00:00
static struct stasis_rest_handlers channels_channelId_snoop = {
. path_segment = " snoop " ,
. callbacks = {
[ AST_HTTP_POST ] = ast_ari_channels_snoop_channel_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
. num_children = 1 ,
. children = { & channels_channelId_snoop_snoopId , }
2013-11-23 12:40:46 +00:00
} ;
/*! \brief REST handler for /api-docs/channels.{format} */
2013-04-22 14:58:53 +00:00
static struct stasis_rest_handlers channels_channelId = {
. path_segment = " channelId " ,
. is_wildcard = 1 ,
. callbacks = {
2013-11-07 21:10:31 +00:00
[ AST_HTTP_GET ] = ast_ari_channels_get_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
[ AST_HTTP_POST ] = ast_ari_channels_originate_with_id_cb ,
2013-11-07 21:10:31 +00:00
[ AST_HTTP_DELETE ] = ast_ari_channels_hangup_cb ,
2013-04-22 14:58:53 +00:00
} ,
ARI/PJSIP: Add the ability to redirect (transfer) a channel in a Stasis app
This patch adds a new feature to ARI to redirect a channel to another server,
and fixes a few bugs in PJSIP's handling of the Transfer dialplan
application/ARI redirect capability.
*New Feature*
A new operation has been added to the ARI channels resource, redirect. With
this, a channel in a Stasis application can be redirected to another endpoint
of the same underlying channel technology.
*Bug fixes*
In the process of writing this new feature, two bugs were fixed in the PJSIP
stack:
(1) The existing .transfer channel callback had the limitation that it could
only transfer channels to a SIP URI, i.e., you had to pass
'PJSIP/sip:foo@my_provider.com' to the dialplan application. While this is
still supported, it is somewhat unintuitive - particularly in a world full
of endpoints. As such, we now also support specifying the PJSIP endpoint to
transfer to.
(2) res_pjsip_multihomed was, unfortunately, trying to 'help' a 302 redirect by
updating its Contact header. Alas, that resulted in the forwarding
destination set by the dialplan application/ARI resource/whatever being
rewritten with very incorrect information. Hence, we now don't bother
updating an outgoing response if it is a 302. Since this took a looong time
to find, some additional debug statements have been added to those modules
that update the Contact headers.
Review: https://reviewboard.asterisk.org/r/4316/
ASTERISK-24015 #close
Reported by: Private Name
ASTERISK-24703 #close
Reported by: Matt Jordan
........
Merged revisions 431717 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431718 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2015-02-12 20:34:37 +00:00
. num_children = 13 ,
. children = { & channels_channelId_continue , & channels_channelId_redirect , & channels_channelId_answer , & channels_channelId_ring , & channels_channelId_dtmf , & channels_channelId_mute , & channels_channelId_hold , & channels_channelId_moh , & channels_channelId_silence , & channels_channelId_play , & channels_channelId_record , & channels_channelId_variable , & channels_channelId_snoop , }
2013-04-22 14:58:53 +00:00
} ;
/*! \brief REST handler for /api-docs/channels.{format} */
static struct stasis_rest_handlers channels = {
. path_segment = " channels " ,
. callbacks = {
2013-11-07 21:10:31 +00:00
[ AST_HTTP_GET ] = ast_ari_channels_list_cb ,
[ AST_HTTP_POST ] = ast_ari_channels_originate_cb ,
2013-04-22 14:58:53 +00:00
} ,
. num_children = 1 ,
. children = { & channels_channelId , }
} ;
static int load_module ( void )
{
2013-07-03 16:32:00 +00:00
int res = 0 ;
2013-05-10 17:12:57 +00:00
stasis_app_ref ( ) ;
2013-07-27 23:11:02 +00:00
res | = ast_ari_add_handler ( & channels ) ;
2013-07-03 16:32:00 +00:00
return res ;
2013-04-22 14:58:53 +00:00
}
static int unload_module ( void )
{
2013-07-27 23:11:02 +00:00
ast_ari_remove_handler ( & channels ) ;
2013-05-10 17:12:57 +00:00
stasis_app_unref ( ) ;
2013-04-22 14:58:53 +00:00
return 0 ;
}
2013-06-24 21:40:52 +00:00
AST_MODULE_INFO ( ASTERISK_GPL_KEY , AST_MODFLAG_DEFAULT , " RESTful API module - Channel 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 ,
2013-07-27 23:11:02 +00:00
. nonoptreq = " res_ari,res_stasis " ,
2015-05-06 00:49:04 +00:00
) ;