2013-04-22 14:58:53 +00:00
{
"_copyright" : "Copyright (C) 2012 - 2013, Digium, Inc." ,
"_author" : "David M. Lee, II <dlee@digium.com>" ,
"_svn_revision" : "$Revision$" ,
"apiVersion" : "0.0.1" ,
"swaggerVersion" : "1.1" ,
"basePath" : "http://localhost:8088/stasis" ,
"resourcePath" : "/api-docs/bridges.{format}" ,
"apis" : [
{
"path" : "/bridges" ,
"description" : "Active bridges" ,
"operations" : [
{
"httpMethod" : "GET" ,
"summary" : "List active bridges." ,
"nickname" : "getBridges" ,
"responseClass" : "List[Bridge]"
} ,
{
"httpMethod" : "POST" ,
"summary" : "Create a new bridge." ,
"notes" : "This bridge persists until it has been shut down, or Asterisk has been shut down." ,
"nickname" : "newBridge" ,
"responseClass" : "Bridge" ,
"parameters" : [
{
"name" : "type" ,
"description" : "Type of bridge to create." ,
"paramType" : "query" ,
"required" : false ,
"allowMultiple" : false ,
"dataType" : "string" ,
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
"allowableValues" : {
"valueType" : "LIST" ,
2013-04-22 14:58:53 +00:00
"values" : [
2013-06-18 14:30:06 +00:00
"mixing" ,
2013-04-22 14:58:53 +00:00
"holding"
]
}
}
]
}
]
} ,
{
"path" : "/bridges/{bridgeId}" ,
"description" : "Individual bridge" ,
"operations" : [
{
"httpMethod" : "GET" ,
"summary" : "Get bridge details." ,
"nickname" : "getBridge" ,
"responseClass" : "Bridge" ,
"parameters" : [
{
"name" : "bridgeId" ,
"description" : "Bridge's id" ,
"paramType" : "path" ,
"required" : true ,
"allowMultiple" : false ,
"dataType" : "string"
}
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
] ,
"errorResponses" : [
{
"code" : 404 ,
"reason" : "Bridge not found"
}
2013-04-22 14:58:53 +00:00
]
} ,
{
"httpMethod" : "DELETE" ,
2013-06-10 13:07:11 +00:00
"summary" : "Shut down a bridge." ,
2013-04-22 14:58:53 +00:00
"notes" : "If any channels are in this bridge, they will be removed and resume whatever they were doing beforehand." ,
"nickname" : "deleteBridge" ,
"responseClass" : "void" ,
"parameters" : [
{
"name" : "bridgeId" ,
"description" : "Bridge's id" ,
"paramType" : "path" ,
"required" : true ,
"allowMultiple" : false ,
"dataType" : "string"
}
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
] ,
"errorResponses" : [
{
"code" : 404 ,
"reason" : "Bridge not found"
}
2013-04-22 14:58:53 +00:00
]
}
]
} ,
{
"path" : "/bridges/{bridgeId}/addChannel" ,
"description" : "Add a channel to a bridge" ,
"operations" : [
{
"httpMethod" : "POST" ,
"summary" : "Add a channel to a bridge." ,
"nickname" : "addChannelToBridge" ,
"responseClass" : "void" ,
"parameters" : [
{
"name" : "bridgeId" ,
"description" : "Bridge's id" ,
"paramType" : "path" ,
"required" : true ,
"allowMultiple" : false ,
"dataType" : "string"
} ,
{
"name" : "channel" ,
2013-08-02 14:36:32 +00:00
"description" : "Ids of channels to add to bridge" ,
2013-04-22 14:58:53 +00:00
"paramType" : "query" ,
"required" : true ,
"allowMultiple" : true ,
"dataType" : "string"
2013-08-05 16:59:13 +00:00
} ,
{
"name" : "role" ,
"description" : "Channel's role in the bridge" ,
"paramType" : "query" ,
"required" : false ,
"allowMultiple" : false ,
"dataType" : "string"
2013-04-22 14:58:53 +00:00
}
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
] ,
"errorResponses" : [
{
"code" : 404 ,
"reason" : "Bridge not found"
} ,
{
"code" : 409 ,
"reason" : "Bridge not in Stasis application"
} ,
{
"code" : 422 ,
"reason" : "Channel not found, or not in Stasis application"
}
2013-04-22 14:58:53 +00:00
]
}
]
} ,
{
"path" : "/bridges/{bridgeId}/removeChannel" ,
"description" : "Remove a channel from a bridge" ,
"operations" : [
{
"httpMethod" : "POST" ,
"summary" : "Remove a channel from a bridge." ,
"nickname" : "removeChannelFromBridge" ,
"responseClass" : "void" ,
"parameters" : [
{
"name" : "bridgeId" ,
"description" : "Bridge's id" ,
"paramType" : "path" ,
"required" : true ,
"allowMultiple" : false ,
"dataType" : "string"
} ,
{
"name" : "channel" ,
2013-08-02 14:36:32 +00:00
"description" : "Ids of channels to remove from bridge" ,
2013-04-22 14:58:53 +00:00
"paramType" : "query" ,
"required" : true ,
"allowMultiple" : true ,
"dataType" : "string"
}
]
}
]
} ,
2013-07-19 19:35:21 +00:00
{
"path" : "/bridges/{bridgeId}/play" ,
"description" : "Play media to the participants of a bridge" ,
"operations" : [
{
"httpMethod" : "POST" ,
"summary" : "Start playback of media on a bridge." ,
"notes" : "The media URI may be any of a number of URI's. You may use http: and https: URI's, as well as sound: and recording: URI's. This operation creates a playback resource that can be used to control the playback of media (pause, rewind, fast forward, etc.)" ,
"nickname" : "playOnBridge" ,
"responseClass" : "Playback" ,
"parameters" : [
{
"name" : "bridgeId" ,
"description" : "Bridge's id" ,
"paramType" : "path" ,
"required" : true ,
"allowMultiple" : false ,
"dataType" : "string"
} ,
{
"name" : "media" ,
"description" : "Media's URI to play." ,
"paramType" : "query" ,
"required" : true ,
"allowMultiple" : false ,
"dataType" : "string"
} ,
{
"name" : "lang" ,
"description" : "For sounds, selects language for sound." ,
"paramType" : "query" ,
"required" : false ,
"allowMultiple" : false ,
"dataType" : "string"
} ,
{
"name" : "offsetms" ,
"description" : "Number of media to skip before playing." ,
"paramType" : "query" ,
"required" : false ,
"allowMultiple" : false ,
"dataType" : "int" ,
"defaultValue" : 0 ,
"allowableValues" : {
"valueType" : "RANGE" ,
"min" : 0
}
} ,
{
"name" : "skipms" ,
"description" : "Number of milliseconds to skip for forward/reverse operations." ,
"paramType" : "query" ,
"required" : false ,
"allowMultiple" : false ,
"dataType" : "int" ,
"defaultValue" : 3000 ,
"allowableValues" : {
"valueType" : "RANGE" ,
"min" : 0
}
}
] ,
"errorResponses" : [
{
"code" : 404 ,
"reason" : "Bridge not found"
} ,
{
"code" : 409 ,
"reason" : "Bridge not in a Stasis application"
}
]
}
]
} ,
2013-04-22 14:58:53 +00:00
{
"path" : "/bridges/{bridgeId}/record" ,
"description" : "Record audio on a bridge" ,
"operations" : [
{
"httpMethod" : "POST" ,
"summary" : "Start a recording." ,
"notes" : "This records the mixed audio from all channels participating in this bridge." ,
"nickname" : "recordBridge" ,
"responseClass" : "LiveRecording" ,
"parameters" : [
{
"name" : "bridgeId" ,
"description" : "Bridge's id" ,
"paramType" : "path" ,
"required" : true ,
"allowMultiple" : false ,
"dataType" : "string"
} ,
{
"name" : "name" ,
"description" : "Recording's filename" ,
"paramType" : "query" ,
"required" : true ,
"allowMultiple" : false ,
"dataType" : "string"
} ,
2013-07-19 19:35:21 +00:00
{
"name" : "format" ,
"description" : "Format to encode audio in" ,
"paramType" : "query" ,
"required" : true ,
2013-08-02 14:36:32 +00:00
"allowMultiple" : false ,
2013-07-19 19:35:21 +00:00
"dataType" : "string"
} ,
2013-04-22 14:58:53 +00:00
{
"name" : "maxDurationSeconds" ,
"description" : "Maximum duration of the recording, in seconds. 0 for no limit." ,
"paramType" : "query" ,
"required" : false ,
"allowMultiple" : false ,
"dataType" : "int" ,
2013-07-19 19:35:21 +00:00
"defaultValue" : 0 ,
"allowableValues" : {
"valueType" : "RANGE" ,
"min" : 0
}
2013-04-22 14:58:53 +00:00
} ,
{
"name" : "maxSilenceSeconds" ,
"description" : "Maximum duration of silence, in seconds. 0 for no limit." ,
"paramType" : "query" ,
"required" : false ,
"allowMultiple" : false ,
"dataType" : "int" ,
2013-07-19 19:35:21 +00:00
"defaultValue" : 0 ,
"allowableValues" : {
"valueType" : "RANGE" ,
"min" : 0
}
2013-04-22 14:58:53 +00:00
} ,
{
2013-07-19 19:35:21 +00:00
"name" : "ifExists" ,
"description" : "Action to take if a recording with the same name already exists." ,
2013-04-22 14:58:53 +00:00
"paramType" : "query" ,
"required" : false ,
"allowMultiple" : false ,
2013-07-19 19:35:21 +00:00
"dataType" : "string" ,
"defaultValue" : "fail" ,
"allowableValues" : {
"valueType" : "LIST" ,
"values" : [
"fail" ,
"overwrite" ,
"append"
]
}
2013-04-22 14:58:53 +00:00
} ,
{
"name" : "beep" ,
"description" : "Play beep when recording begins" ,
"paramType" : "query" ,
"required" : false ,
"allowMultiple" : false ,
"dataType" : "boolean" ,
"defaultValue" : false
} ,
{
"name" : "terminateOn" ,
"description" : "DTMF input to terminate recording." ,
"paramType" : "query" ,
"required" : false ,
"allowMultiple" : false ,
"dataType" : "string" ,
"defaultValue" : "none" ,
"allowableValues" : {
"valueType" : "LIST" ,
"values" : [
"none" ,
"any" ,
"*" ,
"#"
]
}
}
]
}
]
}
] ,
"models" : {
"Bridge" : {
"id" : "Bridge" ,
Update events to use Swagger 1.3 subtyping, and related aftermath
This patch started with the simple idea of changing the /events data
model to be more sane. The original model would send out events like:
{ "stasis_start": { "args": [], "channel": { ... } } }
The event discriminator was the field name instead of being a value in
the object, due to limitations in how Swagger 1.1 could model objects.
While technically sufficient in communicating event information, it was
really difficult to deal with in terms of client side JSON handling.
This patch takes advantage of a proposed extension[1] to Swagger which
allows type variance through the use of a discriminator field. This had
a domino effect that made this a surprisingly large patch.
[1]: https://groups.google.com/d/msg/wordnik-api/EC3rGajE0os/ey_5dBI_jWcJ
In changing the models, I also had to change the swagger_model.py
processor so it can handle the type discriminator and subtyping. I took
that a big step forward, and using that information to generate an
ari_model module, which can validate a JSON object against the Swagger
model.
The REST and WebSocket generators were changed to take advantage of the
validators. If compiled with AST_DEVMODE enabled, JSON objects that
don't match their corresponding models will not be sent out. For REST
API calls, a 500 Internal Server response is sent. For WebSockets, the
invalid JSON message is replaced with an error message.
Since this took over about half of the job of the existing JSON
generators, and the .to_json virtual function on messages took over the
other half, I reluctantly removed the generators.
The validators turned up all sorts of errors and inconsistencies in our
data models, and the code. These were cleaned up, with checks in the
code generator avoid some of the consistency problems in the future.
* The model for a channel snapshot was trimmed down to match the
information sent via AMI. Many of the field being sent were not
useful in the general case.
* The model for a bridge snapshot was updated to be more consistent
with the other ARI models.
Another impact of introducing subtyping was that the swagger-codegen
documentation generator was insufficient (at least until it catches up
with Swagger 1.2). I wanted it to be easier to generate docs for the API
anyways, so I ported the wiki pages to use the Asterisk Swagger
generator. In the process, I was able to clean up many of the model
links, which would occasionally give inconsistent results on the wiki. I
also added error responses to the wiki docs, making the wiki
documentation more complete.
Finally, since Stasis-HTTP will now be named Asterisk REST Interface
(ARI), any new functions and files I created carry the ari_ prefix. I
changed a few stasis_http references to ari where it was non-intrusive
and made sense.
(closes issue ASTERISK-21885)
Review: https://reviewboard.asterisk.org/r/2639/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393529 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-07-03 16:32:41 +00:00
"description" : "The merging of media from one or more channels.\n\nEveryone on the bridge receives the same audio." ,
2013-04-22 14:58:53 +00:00
"properties" : {
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
"id" : {
"type" : "string" ,
"description" : "Unique identifier for this bridge" ,
"required" : true
} ,
"technology" : {
"type" : "string" ,
"description" : "Name of the current bridging technology" ,
"required" : true
} ,
"bridge_type" : {
2013-04-22 14:58:53 +00:00
"type" : "string" ,
"description" : "Type of bridge technology" ,
"required" : true ,
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
"allowableValues" : {
"valueType" : "LIST" ,
2013-04-22 14:58:53 +00:00
"values" : [
2013-06-18 14:30:06 +00:00
"mixing" ,
2013-04-22 14:58:53 +00:00
"holding"
]
}
} ,
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
"bridge_class" : {
"type" : "string" ,
"description" : "Bridging class" ,
"required" : true
} ,
2013-04-22 14:58:53 +00:00
"channels" : {
"type" : "List[string]" ,
2013-08-02 14:36:32 +00:00
"description" : "Ids of channels participating in this bridge" ,
2013-04-22 14:58:53 +00:00
"required" : true
}
}
}
}
}
