[asterisk-dev] [Code Review] 2621: Shuffle RESTful URL's around

David Lee reviewboard at asterisk.org
Wed Jul 3 12:10:48 CDT 2013


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/2621/
-----------------------------------------------------------

(Updated July 3, 2013, 12:10 p.m.)


Status
------

This change has been marked as submitted.


Review request for Asterisk Developers and Joshua Colp.


Bugs: ASTERISK-21857
    https://issues.asterisk.org/jira/browse/ASTERISK-21857


Repository: Asterisk


Description
-------

This patch moves the RESTful URL's around to more appropriate
locations for release.

The /stasis URL's are moved to /ari, since Asterisk RESTful Interface
was a more appropriate name than Stasis-HTTP. (Most of the code still
has stasis_http references, but they will be cleaned up after there
are no more outstanding branches that would have merge conflicts with
such a change).

A larger change was moving the ARI events WebSocket off of the shared
/ws URL to its permanent home on /ari/events. The Swagger code
generator was extended to handle "upgrade: websocket" and
"websocketProtocol:" attributes on an operation.

The WebSocket module was modified to better handle WebSocket servers
that have a single registered protocol handler. If a client
connections does not specify the Sec-WebSocket-Protocol header, and
the server has a single protocol handler registered, the WebSocket
server will go ahead and accept the client for that subprotocol.


Diffs
-----

  /trunk/include/asterisk/stasis_http.h 392462 
  /trunk/res/Makefile 392462 
  /trunk/res/res_http_websocket.c 392462 
  /trunk/res/res_http_websocket.exports.in 392462 
  /trunk/res/res_stasis_http.c 392462 
  /trunk/res/res_stasis_http.exports.in 392462 
  /trunk/res/res_stasis_http_asterisk.c 392462 
  /trunk/res/res_stasis_http_bridges.c 392462 
  /trunk/res/res_stasis_http_channels.c 392462 
  /trunk/res/res_stasis_http_endpoints.c 392462 
  /trunk/res/res_stasis_http_events.c 392462 
  /trunk/res/res_stasis_http_playback.c 392462 
  /trunk/res/res_stasis_http_recordings.c 392462 
  /trunk/res/res_stasis_http_sounds.c 392462 
  /trunk/res/res_stasis_websocket.c 392462 
  /trunk/res/stasis_http/ari_websockets.c PRE-CREATION 
  /trunk/res/stasis_http/resource_events.h 392462 
  /trunk/res/stasis_http/resource_events.c 392462 
  /trunk/rest-api-templates/asterisk_processor.py 392462 
  /trunk/rest-api-templates/param_parsing.mustache PRE-CREATION 
  /trunk/rest-api-templates/res_stasis_http_resource.c.mustache 392462 
  /trunk/rest-api-templates/rest_handler.mustache 392462 
  /trunk/rest-api-templates/stasis_http_resource.c.mustache 392462 
  /trunk/rest-api-templates/stasis_http_resource.h.mustache 392462 
  /trunk/rest-api-templates/swagger_model.py 392462 
  /trunk/rest-api/api-docs/events.json 392462 
  /trunk/tests/test_stasis_http.c 392462 

Diff: https://reviewboard.asterisk.org/r/2621/diff/


Testing
-------

* Ran some ARI tests against /ari/events
  * Specifying the 'ari' subprotocol
  * Specifying no subprotocol
  * Specifying any other subprotocol got a 400 response
* Verified that connecting to /ws echo subprotocol still worked


Thanks,

David Lee

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20130703/5fc74e89/attachment.htm>


More information about the asterisk-dev mailing list