Act Voyager Report
Wed, 03-Jun-2015 by
Elizabeth Mattijsen
edit post
<![CDATA[
The Act - Voyager project has not come to a halt, although it has been a bit silent. My apologies for those who had been waiting last month for the report.
Life has taken some turns, in my favour, and thanks to Rick Deller from Eligo, I got a nice job at Broadbean technologies in London - and yes, moved from my lovely little hometown to the Perl capital of the United Kingdom, and met some great people at work or during the London pm activities.
The few hours left, I kept pushing forward the project, little by little. And I am very happy with the direction it is going and below I will try to explain what has happend with the basics of the REST-api. But before that, I think I should mention that the Act-Voyager project will leave behind the legacy system. It has served the community for more than a decade and during that time changes have been made to fulfil the needs organisers had. But in that process some decisions also have led to not such nice solutions. Things will need to change and a nice REST-api should come from the drawing-board...
REST api's deal with resources, indicated by an URL... the new structure will be:
https://example.com/yapc_na/2015/...
The first level (which I called a syndicate) functions as a kind of aggregate for the events organised under that 'authority'... in this example... the 2015 edition of the YAPC-NA. In the future I would love to see it happen that we could use it also for the monthly pm-meetings, like
https://example.com/amsterdam-x/2015_12/...
So, in the future, the api will simply deliver the news about YAPC-NA at the resource:
https://example.com/yapc_na/news
and if you only want the news for the 2016 edition
https://example.com/yapc_na/2016
The design is slightly deviant from other URL patterns, normally it would be more tedious: https://example.com/syndicate/yapc_na/edition/2016/news or the other approach would be using tons of filters.
Another important thing in designing a REST-api is the decoupling between the REST resource representations and that actual data-store. In other words, the Act-Voyager REST resources are not being a 1 to 1 translation of the legacy-tables, but will be composed from different tables. At a few occasions in Cluj, Amsterdam-X, German Perlworkshop, I gave a presentation about multi-lingual REST api's and did address the decoupling and how a REST api should use a abstraction layer which does all the hard work - not your Dancer2 app.
Add on top of that the fact that Act has a 'rights' table that holds the information for a conference and a user and what rights he / she has, and it becomes obvious that it was not going to be a simple Dancer2 dispatch app. For the authentication I modified some previous work I did for a plugin: Dancer2::Plugin::HTTP::Auth::Extensible.
Bolting all things together, I came up with a REST::api::Handler... one that can do only very simple tasks... dispatch the work to the REST::api::Objects, REST::api::Collections or REST::api::DataStore. Now, instead of having all these different methods in one huge module, I put them in smaller modules, Moo::Roles to be more specific. And each of these roles will be applied to the Handler object, based on the context... a ResourceRoot and a ClientUser.
inside Dancer2, it looks just like:
post '/news' http_require_task 'insert_news' => sub { http_handler->insert_news(...) };
And the handler knows if and on what level to dispatch the request to the REST api datastore.
I personally think, Act Voyager is going to have a save journey now
NB: for the brave... <a href="https://github.com/Act-Voyager/Act/tree/REST-api">check it out on Github</a>
Theo van Hoesel
#act
]]>
Comments (0)
