Suppose you have a new project, and suppose part of that project involves server-side web programming. Suppose the client would also like a RESTful interface as well as the web interface.
Assume that you don't have complete control over who else to hire for the project, but that you can specify sufficient familiarity with Perl and web programming.
What resources would you give to the other programmers to help them design, implement, and maintain a RESTful web application written primarily in Perl? Assume that you don't have time for a two day immersion class (because you'd have to teach it, after all), and that you can hand out the RESTful Web Services book and tell people "Overlook that silly Ruby code."
Assume that the Perl framework used for the website is Catalyst, and that you have access to the full Plack ecosystem.
First I would explain to the new hirelings that the phrase “a RESTful interface as well as the web interface” is misleading, as a RESTful interface is the Web Interface. If it’s not, you’re doing it wrong.
I would hand them REST In Practice, which has hateful Java and C# code rather than Ruby code, but has an excellent understanding of REST and HATEOAS. I would tell them to go read the TAG Findings which explains why I am so adamant that REST == The Web. I would have them read about the Richardson Machurity Model even if it’s an imperfect start to describing REST. I would have them read this, and this and this.
Finally for extra credit I would have them read Roy Fielding’s actual paper.
er "Richards Maturity Model" ... dang spell check.
If you're doing REST with Catalyst the (somewhat badly named) Catalyst-Action-REST distro is invaluable. It makes it easy to dispatch based on the combination of URI and HTTP method.
If you're building an app that needs to be used by browsers as well as other REST clients, you should really take a look at the "::ForBrowsers" classes in that distro. Those classes will let you route browsers to the PUT and DELETE methods, and let you generate browser-specific GET responses (HTML pages vs resources as JSON/XML/etc).
Finally, they should consider my CatalystX::Routes module. It adds another layer of sugar for dispatch declaration, and as a bonus gets rid of the hideous subroutine attributes most Catalyst apps use. Unfortunately, it replaces with something only a little less hideous ;)
As autarch hints at in comment 3, the routing concept makes handling REST easy. In addition to the countless routing modules built into frameworks such as Catalyst, there are a number of stand-alone routing packages, in no particular order: Forward-Route, HTTP-Router, Path-Router, Router-Resource, Router-Simple, Routes-Tiny. I'm a fan of Router-Resource which extends Plack nicely.
I would second the "REST in Practice" recommendation, though it's not a light/fast read. Tell the reader to skip chapters that aren't particularly relevant (e.g. Atom Publishing Protocol). The early chapters are probably enough to get the project started, and they can finish the book as the project continues.
What Every Developer Should Know About URLs
http://www.skorks.com/2010/05/what-every-developer-should-know-about-urls/
Regardless of language or frameworks I find, like the author, that many developers do not understand or appreciate how URLs work.
Developing RESTful Web Services in Perl
http://onlamp.com/pub/a/onlamp/2008/02/19/developing-restful-web-services-in-perl.html
Not the most current thing, but it covers the basics and in basic Perl terms. What's missing is the use of the latest libraries and frameworks available.