[Dancer-users] RESTful applications in Dancer

[damien krotkine]

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.


dams
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.backup-manager.org/pipermail/dancer-users/attachments/20101220/17b6ac2a/attachment-0001.htm>