http://qs321.pair.com?node_id=1093309

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

I am building a simple web tool for a client. It will query a database and display some data. They will be able to search, sort, etc., so a simple javascript tool can handle the display. I want to use perl on the back end, as I have done in other situations. It has been suggested that I implement it via REST and then I can add new features fairly easily (this client likes to request that).

I've read modern ways of doing web services. I've also read Apache2::REST. I don't see many servers using the latter, even though it looks good. Is something better? I don't want to do it all from scratch, of course.

Replies are listed 'Best First'.
Re: Is REST best?
by perlfan (Vicar) on Jul 11, 2014 at 20:49 UTC
    Building up your application with a separation between a RESTful service API and one of many potential clients using a JS web frontend is a great idea.

    There are many ways to get started quickly, but I would recommend Dancer or if you're constrained to a CGI environment, using CGI::Application with CGI::Application::Dispatch. Others here will have similar and equally valid suggestions.

[reply]

      I concur with perlfan, but I suggest looking at Dancer2 instead of Dancer based on what was being said by some notable personages at YAPCNA:2014. Note, I haven't had occasion to play with it yet, this is based solely on various discussions held mainly during the after-hours booze sessions. (perlfan was a part of some of them, but can be forgiven if he does not have a complete recollection of them. :) )

      You must always remember that the primary goal is to drain the swamp even when you are hip-deep in alligators.
[reply]
Re: Is REST best?
by sundialsvc4 (Abbot) on Jul 12, 2014 at 00:40 UTC

    REST isn’t my personal favorite, partly because I really don’t want to put things in a URL-string that is so easily manipulated ... unless it actually makes sense (and is possible) for the user to reasonably specify a RESTful URL-string entirely on his own.   (Or when it is both meaningful and harmless for me to build clickable hyperlinks.)   Otherwise, I tend to define a single /api entry-point and to use JSON in both directions.   The API simply implements a remote-procedure-call type of interface, and the URL-string means nothing.

    A good example where REST might make perfect sense is in, say, a list of songs on a music site.   In that case, a URL-string of /song/nnnn, where nnnn is a song-number, might be just what the doc ordered.   But if it is strictly meant to be a program-to-program interface, I don’t ordinarily choose that route.

[reply]
      RESTful URLs are minimal. Query strings are discouraged, and most data is passed in the request in some serialized format. Couple this with the HTTP method and you get a much easier to maintain dispatching situation on the server. Sanitizing what is in any request you send is just part of the deal, it doesn't matter if it's in the URL or not. So I am not sure I get your issue.
[reply]

        So I am not sure I get your issue.

        sundialsvc4 is the biggest troll on perlmonks, thats about the sum of it

[reply]
Re: Is REST best?
by traveler (Parson) on Jul 15, 2014 at 21:00 UTC

    I am using Dancer2. So far it has been easy - the Cookbook really helps. I am just testing with HTML now, and I need try the session stuff.

    Thanks all, for the assistance.

[reply]

Back to Seekers of Perl Wisdom