Beefy Boxes and Bandwidth Generously Provided by pair Networks
Your skill will accomplish
what the force of many cannot

pointers for creating a persistent RESTful server using Moose

by addinall (Novice)
on Mar 09, 2012 at 12:42 UTC ( [id://958699] : perlquestion . print w/replies, xml ) Need Help??

addinall has asked for the wisdom of the Perl Monks concerning the following question:

Hiya, been a while...

I decided to re-write an OLD project using new techniques. This is not a "show me how to do my homework" question, I just keep reading around in circles, so here goes.

What I would like to code is a persistent SERVER in Perl that accepts a RESTful transaction from a PHP page running.

The Perl server accepts the transaction, sanity and security tests the CRUD request then makes an SNMP connection with a third network element (switch on the net) and returns the gathered MIB information back up to the RESTful caller in the PHP/Javascript code.

If this isn't bad enough ;-) I want to write the Perl server using Moose.

Any pointers Monks? I have been reading HTML::Engine and Plack. Nothing seems to quite fit.

+------------+ | | | web page | | <TEST> |-------->+------------------+ | | | Perl Server | +------------+ | SNMP::Something | ^ +------------------+ |_____________| | ^ | | +---\/----------+ | CISCO IOS MIB | +---------------+

My old way, the server is just a once off transaction and the message passing is a kludge using stdio and stderr and the code is awful!!!

All pointers appreciated. Ta. Marky.

Thanks for the suggestion (see title) and the links. I have Modern Perl, read it heaps of times and even implemented some code in a serious environment! But I need to sort this particular thingy out. Thanks for the stuff. The more the merrier... :-)

Replies are listed 'Best First'.
Re: Moose and Antlers!
by Anonymous Monk on Mar 09, 2012 at 13:07 UTC
Re: Moose and Antlers!
by Anonymous Monk on Mar 09, 2012 at 13:24 UTC
Re: pointers for creating a persistent RESTful server using Moose
by RichardK (Parson) on Mar 09, 2012 at 16:58 UTC

    I found Mojolicious quite easy and I quickly developed a restful interface to a database when I needed it. My project was only small and had limited use, so I can't comment on high volume sites. But you might find it useful to have a look at.

Re: pointers for creating a persistent RESTful server using Moose
by sundialsvc4 (Abbot) on Mar 09, 2012 at 15:48 UTC

    When I had to do a very similar thing, I quickly decided that “RESTful is for the birds.”   I decided that it was both cumbersome and unnecessary to put parameters into a URL-string:   just put them in a JSON or XML packet, which can contain whatever information you want (including things that give URL-strings grief, such as product-id like PQ345/Z which contains a slash).   Sure, you can work around things like that in a REST string, but ... why bother?   After all, the URL-string is only one of several parts of the HTTP-block that you are sending and receiving.   Why use GET when you can POST?

    After scoping the field, I used RPC::Any as a recently-developed and very well-developed infrastructure on the Perl side.   The client simply POSTs an XML or JSON packet to the server, and gets a similar packet in return.   The analogy is just like any sort of subroutine-call in which you send a structure (hash...) as your parameter-list and you get one back as your result.

    Very simply, I think that “monkeying around with putting parameters in a URL string,” i.e. REST, is one of those ideas that might look great on paper, but that’s a PITA in practice.   It’s also a PITA that doesn’t buy you anything, given that you can do exactly the same thing with XML/JSON with none of the inherent restrictions.   Your Perl handlers get a hash as input, and they return a hash (or throw an exception, which is caught...) in return.   Q.E.D.

    Three other things proved very helpful to me in my recent project:

    1. In an initial handshake with the server, the client (PHP...) introduces itself and gets back a random token (like a cookie .. it could be a cookie) generated by the server which it must provide in all subsequent requests.   This gives the server complete and secure access to whatever context-information it may have need to store locally.
    2. For each request of any kind that the client sends to the server, the client provides a separate random-string which the server must return verbatim with any reply, whether success or failure.   The client uses this to match-up requests with replies.
    3. If requests might be coming from different sources within the client-side, arrange for the packets that are sent to contain perhaps more than one request and more than one reply.   (Since they’re just structured packets of data, you can easily return an array-of one or more such packets, given that each one has been given a distinct ID by the requester.)   It is desirable to minimize the number of times you have to turn-around the TCP/IP or pipe connection, and it is effortless to do so.

    My experience with RPC::Any was, frankly, that I had found the “right” answer for my purposes.   I had it up and running in about two hours, most of that time spent reading.

    Yes, as it happens, the back-end server uses Moose, but notice that it does not have to be Moose-based in order to work properly.   The architecture of this module is that it “demand-loads” the various handler modules, and it recognizes them without any “decorations” at all.   A modular and low-footprint server can be constructed very quickly, and I can see from the contributor’s description that this is what it’s doing in service at his place of business.

      ... blah blah blah i don't know what REST means ....

      Rest means GET/PUT/POST/DELETE