[Dancer-users] RESTful applications in Dancer

[Naveed Massjouni]

On Mon, Dec 20, 2010 at 12:13 PM, damien krotkine <dkrotkine at gmail.com> wrote:
>
>
> On 20 December 2010 16:12, Gabor Szabo <szabgab at gmail.com> wrote:
>>
>> On Mon, Dec 20, 2010 at 4:34 PM, damien krotkine <dkrotkine at gmail.com>
>> wrote:
>> >
>> > First, I'd suggest that you think about what makes your webapp RESTy ?
>>
>> Well, I don't have a clue what makes and application RESTy but as I
>> understood
>> there are not many people who understand that. :)
>
> You might want to read : http://oreilly.com/catalog/9780596529260
> Writing a web service which is half REST, half classical is imho way worse
> than writing your web service in old school way.
>
>>
>> > It's not because a webapp returns YYML/JSON that it is RESTy. To be REST
>> > oriented, the bare minimum is to have the logic of your app based on
>> > resources. 'login' is definitely not a resource. It looks like a verb,
>> > like
>> > "please log me on or off or something". In REST, the verbs are only HTTP
>> > verbs. URLs are resources, so you should be able to explain them as
>> > nouns.
>> > That said, maybe you already know all that and took 'login' as a strange
>> > example :)
>>
>> So maybe it would be
>>
>>    GET /authorized_cookie
>>
>> or even
>>
>>    GET /authorized_token
>>
>>
>> instead of  /login ?
>
>
> Hm, I don't think so. I mean, technically yes, you may have a web service
> that requires you to advertize an auth token, but I don't think you need
> that.
> My recommandation would be that you explain what you want to achieve, with
> use-cases :) Then we can come up with examples of resources and which HTTP
> verbs to use.
>
>>
>> In any case it would require some kind of credentials.
>> e.g. username/password  or some way - and I don't know yet how
>> that works - to get authenticated by OpenID or some OAuth
>> based service.
>>
>> I am not sure though if even this is "allowed" in pure REST terms
>> as I can see from
>> http://en.wikipedia.org/wiki/Representational_State_Transfer
>> a RESTful application should be stateless?
>> Does that mean for every request that involves private data I'd need
>> to supply my credentials?
>
> In theory yes. It works well with basic HTTP auth, where login / password is
> passed for each request. It works well for basic https auth as well, for the
> same reasons.
> I suggest you keep authentication for later, and concentrate to the real
> features you want in your app, because learning REST by starting with the
> Auth paradygm is imho a bad idea.
>
>>
>> Anyway, here is an example, which is just the first step in my future
>> application:
>
> Ah here are the explanations :)
>
>>
>> A bookmark storing application. So I'd have operations such as
>> add, delete, change     ITEM
>> list items (with some restirctions)
>> Do these need to map to the HTTP keywords?
>>
>> e.g. fetching all the perl related bookmarks would be
>>
>> GET /bookmarks?title='%perl%'
>>
>> fetching all the details about a single bookmark would be:
>>
>> GET /bookmark/42
>>
>> adding a new one would be
>>
>> POST /bookmark?title='The Perl Web Frameworks'&url=http://perldancer.org/
>
> I usually use POST verbs on plural resources, so POST /bookmarks but that
> may be a bad habit
>
>>
>> PUT /bookmark?id=42&comment="Nice framework"
>>
>> Is that the idea or would using GET in each case ok?
>
> you got the idea right I think. using GET in each case completely destroys
> the REST concept.
>>
>> (Personally I am now trying to implement the API of a web services and it
>> drives me crazy that some requests only work as GET others only as POST
>> and I don't even understand the errors I get from the other requests)
>>
>> Is that right that I have /bookmarks (in plural) above and /bookmark
>> (in singular) in
>> the other requests?
>
> yes
> You should spend a lot of time designing your REST interface (resource names
> + verbs), because that's the important bits, and once it's done and made
> public, you cn't really change it. So make sure you handle all the cases,
> and thatit's future proof, and so on.
> But reading a book on REST is good too :)
>
>>
>> > For authentication, I'd use plack and some auth mechanism.
>> > REST means it's stateless. Usually we accept that Authentication is the
>> > only
>> > state retains accross a RESTy webapp. If you need a very complicated
>> > authentication mechanism, you may end up with resources like
>> > /some/authentication. But these will be nouns, not verbs. But most of
>> > the
>> > time, some plugin/middleware/stuf will provide it for you transparently.
>> > Hope I made some sense and were not off topic
>>
>> This answers my previous question about statelessness and authentication.
>>
>> Yes it was very useful, though I am not sure what did you mean by
>> "plugin/middleware/stuf"
>> and how is plack related to authentication.
>
> I was just saying that maybe plack has some middleware you can use that
> handles authentication for you. I never used one, but it may be worth
> looking at it.

Yes, plack middleware is great for this.  You can have a resource
which is protected by http authentication.  You get this for free with
plack middleware.  For example:

    #!/usr/bin/perl
    use Dancer;
    use Plack::Builder;
    use MyAPI;

    builder {
        # Enable http basic authentication for the /authorization resource
        enable_if { my $env = shift; $env->{PATH_INFO} eq '/authorization' }
            'Plack::Middleware::Auth::Basic', authenticator =>
\&MyAPI::authenticate;
        dance;
    };

MyAPI contains the routes.  Only the '/authorization' route will be
wrapped by the middleware.  You can also use the Auth::Digest
middleware.  A client of this api could do something like:

    my $agent = LWP::UserAgent->new()->credentials($host, $realm, $user, $pass);
    my $authorization = from_json($agent->get('/authorization')->content());

-Naveed

>
> dams
> _______________________________________________
> Dancer-users mailing list
> Dancer-users at perldancer.org
> http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
>
>