First, I'd suggest that you think about what makes your webapp RESTy ?

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 :)

If I were you (but I don't know much about your webapp and its goal), I would design a pure REST application.

- routes would be resource names
- I'd use the Dancer REST plugin to handle serialization
- /url/to/resource would return json or yaml based on Accept header. No Accept header would produce a server error
- /url/to/resource.json would work, as well as yaml.

Then, if you need a web frontend, do an other webapp :) or at least, a different Dancer::App. But Dancer being lightweight, it may be valid to have a completely seperated app. 

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


On 20 December 2010 15:22, Gabor Szabo <szabgab@gmail.com> wrote:
hi,

I have a general web related question and then I wonder which of the
answers can be easily implemented in Dancer?

I am building an application that probably will be mostly just send
out serialized data though I am not 100% sure so I might want to
mix in sending out traditional HTML files as well.
So I wonder what is the "best practice" to write RES-ish application,
one that might also serve HTML?

I thought about a few strategies I am going to describe now
using a single route as an example:

1)
/login    always returns HTML
no XML, JSON, YAML interface
old school, no buzzwords here :)


2)
/login         always returns HTML
/login.yml   returns YAML
/login.json  returns JSON
etc. (some of these might be allowed  some might not)

Q: What is the relationship between the HTML and the YAML?
Is the data returned as YAML the same as would be passed to
the template for generating HTML? How?


3)
/login         returns HTML or YAML or JSON depending on the
Accept header of the request.
In order to fetch the YAML response the request needs to supply:
Accept: application/json

I am not sure if HTTP allows multiple Accept headers and if yes then how
should the application behave?

Otherwise the same as 2 above.

4) No HTML responses at all (only some static pages) so
4.2)  the serialization is the same as in 2) based on extension
4.3)  the serialization is the same as in 3) based on Accept header

Are any of these good strategies? Are there other good ones?
Which one can be implemented in Dancer and how?

regards
  Gabor

--
Gabor Szabo
http://szabgab.com/
_______________________________________________
Dancer-users mailing list
Dancer-users@perldancer.org
http://www.backup-manager.org/cgi-bin/listinfo/dancer-users