First off, anyone that publishes on CPAN has my great respect. Clearly this author knows his stuff, shares it and that's a very good thing. I'm not sure I will become a user of this module, primarily because of the dependencies (Moo, etc), but more to the point I'm not (yet) convinced one needs a complete RESTful framework that sits on top of a web development framework.
Having said that, I reserve the right to change my mind and I imagine the author spent a lot of time thinking of that as well and ultimately concluded this his effort was worthy of the problem. Congrats to Michael on publishing his module and adding another building block or at least reference for Perl developers. I admire that effort and wish I had the time and energy to do the same.
So, do we really need a RESTful API framework?
I'm not sure. Why don't I think we need a RESTful framework? Well, I would hope that that the web framework itself that was chosen is robust enough to implement the RESTful architecture and your API without a lot of overhead or hair pulling. After all, the RESTful architecture is supposed to reflect the stateless and simple nature of the web. Sort of, I guess. Paraphrasing a slide from Michael's presentation, there's not too much one needs from a framework to produce a RESTful API. Here's what we'd like from our framework in order to implement our API.
We need the ability to:
- Parse a URI
- Determine the operation to be performed
- Determine the result format requested by the client
- Retrieve, validate, and deserialize client data
- Retrieve data from the back end
- Serialize data to send back to client
- Set HTTP response headers
- Handle errors
Don't forget authentication...
In practice, I'd also add that a way to authenticate users into your system in an efficient and secure manner is a good thing to have as well. Michael points out that that many people use some state information as part of the authentication process since this is usually an expensive process. There are ways to mitigate the need to maintain state for the purpose of authenticating (like signed requests), however in the end it's your API and you can set the rules however you decide to set the rules. Of course, folks might not like your rules, and decide not to use your API, so adherence to the standards is generally the way to go. ;-)
For those that are thinking this, I'll just come out and say it. Yeah, use Perl, CGI.pm and some other CPAN modules and whip up an API. If you loathe CGI.pm, are a little more ambitious and have a desire for speed, user mod_perl. There's clearly no rocket science here. The RESTful protocol (or more correctly architecture) is fairly straight forward - by design. Let's not make this more complicated than it needs to be people! Agreed. But, as we all know, the devil is in the details and it's not that bad an idea to generalize the details as much as possible to decrease cycle time, reduce errors, centralize maintenance and promote standards. I guess that was Michael's goal and he appears to have achieved it. Nice!
Back to Bedrock...
My little experiment using Bedrock to create a RESTful API has taken me down the path of learning more about the subject. Using Bedrock as a learning tool, I've been able to implement some of the architecture very quickly. The experiment has been refined to produce a template for creating RESTful APIs that I'll share in my next blog. I've found that Bedrock has allowed me to very quickly create new services that comply with the RESTful architecture. I've learned some interesting things, at least they are interesting to me, exploited features of Apache and developed some patterns to enable Bedrock to be used to very quickly to create well documented, compliant RESTful APIs.
More to follow...
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.