their application and can provide some feedback from their experience.
I have an existing set of controllers that initially handled AJAX requests.
The controllers use a common base class that provides REST-like actions.
By creating a controller subclass, say App::Controller::Foo, I get actions
GET, POST, PUT, DELETE for /foo. The base class knows how to work with DBIC
for the Foo Result class and also by default looks for a form
App::Form::Foo. Kind of an auto-crud setup. What data (mostly columns) is
returned for GET is defined by configuration. The code that ends up in the
Foo controller is mostly access control (often by adding to the DBIC
resultset) the base class builds.
What eventually ends up happening is search, create, update, and delete get
called on a resultset.
These controllers essentially provide a useful API into the application as
well as supporting AJAX requests. I now need to add a SOAP API that will
provided the same functionality as the existing REST-like API.
I'm using Catalyst::Controller::SOAP and that gives me a Perl data structure
that represents the SOAP payload. Since I already have the REST actions I'm
wondering if it makes sense to simply flatten the SOAP request and
re-dispatch to the REST actions and make use of the existing logic in these
Is anyone doing something like this? That is, remapping a SOAP request to
REST actions? Would I be better off writing a separate set of
self-contained SOAP controllers?
Also, does anyone have a suggestion how to version an API? That is, say I
have an API method POST /foo to create a new Foo object. Would it be better
to use something like POST /api/rest/version_2/foo?
-------------- next part --------------
An HTML attachment was scrubbed...