Re: [Catalyst] Re: RFC: Catalyst::Controller::REST::DBIC

[Mark Trostler]

Yes sorry - this was not directed at you Dave...
Mark

Dave Rolsky wrote:

On Fri, 16 May 2008, Mark Trostler wrote:

I'm sorry but something just feels wrong about your approach - feels 
like your mixing at matching REST & a UI on top.  Get the REST part 
down first, & then worry about something the browser can see on top of 
it.  I don't think you should let 'what a browser can see' to 
influence the REST design.
Get the primitives, GET to search, POST to insert, PUT to update, and 
DELETE to remove working.
Then you, or someone else, can layer something nice for the browser on 
top of that.  Letting what the 'browser can see (or do)' influence 
your RESTful design is just a bad idea I think if you're trying to 
create a REST controller.


I'm suspecting you didn't mean to address me, even though you replied to 
my message.



-dave

/*==
VegGuide.Org
Your guide to all that's veg
==*/

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/




___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Re: RFC: Catalyst::Controller::REST::DBIC

[Dave Rolsky]

On Fri, 16 May 2008, Mark Trostler wrote:

I'm sorry but something just feels wrong about your approach - feels like 
your mixing at matching REST & a UI on top.  Get the REST part down first, & 
then worry about something the browser can see on top of it.  I don't think 
you should let 'what a browser can see' to influence the REST design.
Get the primitives, GET to search, POST to insert, PUT to update, and DELETE 
to remove working.
Then you, or someone else, can layer something nice for the browser on top of 
that.  Letting what the 'browser can see (or do)' influence your RESTful 
design is just a bad idea I think if you're trying to create a REST 
controller.


I'm suspecting you didn't mean to address me, even though you replied to 
my message.



-dave

/*==
VegGuide.Org
Your guide to all that's veg
==*/

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Re: RFC: Catalyst::Controller::REST::DBIC

[Mark Trostler]

I'm sorry but something just feels wrong about your approach - feels 
like your mixing at matching REST & a UI on top.  Get the REST part down 
first, & then worry about something the browser can see on top of it.  I 
don't think you should let 'what a browser can see' to influence the 
REST design.
Get the primitives, GET to search, POST to insert, PUT to update, and 
DELETE to remove working.
Then you, or someone else, can layer something nice for the browser on 
top of that.  Letting what the 'browser can see (or do)' influence your 
RESTful design is just a bad idea I think if you're trying to create a 
REST controller.
Now if you wanted to create just a generic CRUD controller that sort of 
looked like REST or borrowed some ideas from it, then fine.
I guess the problem myself (& others perhaps) are having is calling what 
 I think you're proposing 'REST'.

Mark

Dave Rolsky wrote:

On Fri, 16 May 2008, Zbigniew Lukasiak wrote:

Why would anyone care about GET vs POST? I guarantee most users don't 
care.


If you mean they want to use a form, that has nothing to do with the 
method.

Forms can submit GET requests.


It might need to be a POST if you need to download a file as one of
the search arguments (for example for searching for a similar
picture).


I think you mean _upload_, right?

The URI you propose could be RESTful, if you think of "search" as a 
noun,

maybe short for "search results".


OK - what I was argumenting about is that sometimes it is convenient
to have an URI like that.  The other part of the argument is that if
you have an uri '/cd/search' - then you should not use '/cd/1' to
retrieve the CD object - because then you mix data with commands (id
with actions).


I have no strong opinion on this. I was just pointing out which URIs 
were RESTful and which weren't.



-dave

/*==
VegGuide.Org
Your guide to all that's veg
==*/

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/




___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Re: RFC: Catalyst::Controller::REST::DBIC

[Dave Rolsky]

On Fri, 16 May 2008, Zbigniew Lukasiak wrote:


Why would anyone care about GET vs POST? I guarantee most users don't care.

If you mean they want to use a form, that has nothing to do with the method.
Forms can submit GET requests.


It might need to be a POST if you need to download a file as one of
the search arguments (for example for searching for a similar
picture).


I think you mean _upload_, right?


The URI you propose could be RESTful, if you think of "search" as a noun,
maybe short for "search results".


OK - what I was argumenting about is that sometimes it is convenient
to have an URI like that.  The other part of the argument is that if
you have an uri '/cd/search' - then you should not use '/cd/1' to
retrieve the CD object - because then you mix data with commands (id
with actions).


I have no strong opinion on this. I was just pointing out which URIs were 
RESTful and which weren't.



-dave

/*==
VegGuide.Org
Your guide to all that's veg
==*/

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Re: RFC: Catalyst::Controller::REST::DBIC

[Zbigniew Lukasiak]

Hi,

I don't know what to do with this thread.

On Fri, May 16, 2008 at 6:31 PM, Dave Rolsky <[EMAIL PROTECTED]> wrote:
> On Fri, 16 May 2008, Zbigniew Lukasiak wrote:
>
 - a search
>>>
>>> I tend to prefer expressing searches with query parameters… hm.
>>
>> I understand that what you propose is '/cd?year=1968', is that right?
>> I really don't know - but some people would prefer to do the search by
>> POST, or might just like to have the uri as '/cd/search?year=1968'.
>
> Why would anyone care about GET vs POST? I guarantee most users don't care.
>
> If you mean they want to use a form, that has nothing to do with the method.
> Forms can submit GET requests.

It might need to be a POST if you need to download a file as one of
the search arguments (for example for searching for a similar
picture).

>
> The URI you propose could be RESTful, if you think of "search" as a noun,
> maybe short for "search results".
>

OK - what I was argumenting about is that sometimes it is convenient
to have an URI like that.  The other part of the argument is that if
you have an uri '/cd/search' - then you should not use '/cd/1' to
retrieve the CD object - because then you mix data with commands (id
with actions).

>>> Example? I can't quite imagine what you would want to do here.
>>
>> Hmm - how about a help screen - conveniently at '/cd/help'?
>
> Again, could be RESTful.
>

Great.  I am only argumenting that sometimes you need such an uri - see above.

> One part of REST is that URIs contain nouns, period. The type of nouns, the
> path hierarchy, all that is irrelevant, the key is that the URI never
> contains a verb like "submit" or "edit". Note that "edit_form" is a noun,
> and is perfectly RESTful, and _necessary_ if you plan to have browsers
> interact with a set of RESTful URIs.

As above.

-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Re: RFC: Catalyst::Controller::REST::DBIC

[Dave Rolsky]

On Fri, 16 May 2008, Zbigniew Lukasiak wrote:


- a search


I tend to prefer expressing searches with query parameters… hm.


I understand that what you propose is '/cd?year=1968', is that right?
I really don't know - but some people would prefer to do the search by
POST, or might just like to have the uri as '/cd/search?year=1968'.


Why would anyone care about GET vs POST? I guarantee most users don't 
care.


If you mean they want to use a form, that has nothing to do with the 
method. Forms can submit GET requests.


The URI you propose could be RESTful, if you think of "search" as a noun, 
maybe short for "search results".



Example? I can't quite imagine what you would want to do here.


Hmm - how about a help screen - conveniently at '/cd/help'?


Again, could be RESTful.

One part of REST is that URIs contain nouns, period. The type of nouns, 
the path hierarchy, all that is irrelevant, the key is that the URI never 
contains a verb like "submit" or "edit". Note that "edit_form" is a noun, 
and is perfectly RESTful, and _necessary_ if you plan to have browsers 
interact with a set of RESTful URIs.



-dave

/*==
VegGuide.Org
Your guide to all that's veg
==*/___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Re: RFC: Catalyst::Controller::REST::DBIC

[Zbigniew Lukasiak]

On Fri, May 16, 2008 at 12:06 PM, Aristotle Pagaltzis <[EMAIL PROTECTED]> wrote:
> * Zbigniew Lukasiak <[EMAIL PROTECTED]> [2008-05-16 06:25]:
>> Hmm - frankly I have never thought out REST entirely - but I
>> have the feeling that it is always better to be cautious (and
>> you know - be liberal in what you receive).
>
> It's like Turing completeness: you can do everything RESTfully
> that you can do in any other way, you just have to model the
> problem in a way that fits the constraints. REST doesn't restrict
> what you can achieve at all, it just imposes some requirements on
> how you go about it.
>
>> Some ideas top of my head:
>>
>> - a login method (the advantage would be that it does not need to redirect)
>
> I'm not sure I follow. You mean you want to have something like
> `/api/rest/cd/login`? And how do you avoid redirecting from that
> if you have `login` in the URI, which isn't where the client
> needs to be looking at?

Yeah - I think you are right, that was just a quick one.

>
>> - a search
>
> I tend to prefer expressing searches with query parameters… hm.

I understand that what you propose is '/cd?year=1968', is that right?
I really don't know - but some people would prefer to do the search by
POST, or might just like to have the uri as '/cd/search?year=1968'.

>
>> - exposing some class data (as opposed to instance data) and
>> maybe class methods?
>
> Example? I can't quite imagine what you would want to do here.

Hmm - how about a help screen - conveniently at '/cd/help'?


In short I think '/cd/instance/1' style of URIs is less interferring
with how people think about structuring their uris.  If you do '/cd/1'
then you force them to choose one way of doing everything - even if it
is a Turing complete way and you can do everything in that style.

-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

[Catalyst] Re: RFC: Catalyst::Controller::REST::DBIC

[Aristotle Pagaltzis]

* Zbigniew Lukasiak <[EMAIL PROTECTED]> [2008-05-16 06:25]:
> Hmm - frankly I have never thought out REST entirely - but I
> have the feeling that it is always better to be cautious (and
> you know - be liberal in what you receive).

It’s like Turing completeness: you can do everything RESTfully
that you can do in any other way, you just have to model the
problem in a way that fits the constraints. REST doesn’t restrict
what you can achieve at all, it just imposes some requirements on
how you go about it.

> Some ideas top of my head:
> 
> - a login method (the advantage would be that it does not need to redirect)

I’m not sure I follow. You mean you want to have something like
`/api/rest/cd/login`? And how do you avoid redirecting from that
if you have `login` in the URI, which isn’t where the client
needs to be looking at?

> - a search

I tend to prefer expressing searches with query parameters… hm.

> - exposing some class data (as opposed to instance data) and
> maybe class methods?

Example? I can’t quite imagine what you would want to do here.

Regards,
-- 
Aristotle Pagaltzis // 

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Re: RFC: Catalyst::Controller::REST::DBIC

[Zbigniew Lukasiak]

On Thu, May 15, 2008 at 11:11 PM, Aristotle Pagaltzis <[EMAIL PROTECTED]> wrote:
> * Zbigniew Lukasiak <[EMAIL PROTECTED]> [2008-05-15 21:25]:
>> On Thu, May 15, 2008 at 7:31 PM, Mark Trostler <[EMAIL PROTECTED]> wrote:
>> > Similarly you don't need 'id' in the url - so POST to
>> > /api/rest/cd will create a cd.  A PUT to /api/rest/cd/5 will
>> > update that CD - a DELETE to /api/rest/cd/5 will delete that
>> > CD...
>>
>> Additionally we would like to have other non REST actions in
>> the same controller. This mixing will require some separation
>> between the method names and the object id (which is data).
>
> You are thinking about it wrong. You don't put method names into
> the URI; you expose more of the state as things to manipulate.
>
> If you give an example of what you mean I can give you one of
> what I mean.

Hmm - frankly I have never thought out REST entirely - but I have the
feeling that it is always better to be cautious (and you know - be
liberal in what you receive).  Some ideas top of my head:

- a login method (the advantage would be that it does not need to redirect)

- a search

- exposing some class data (as opposed to instance data) and maybe
class methods?

Cheers,
Zbigniew Lukasiak
http://brudnopis.blogspot.com/

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

[Catalyst] Re: RFC: Catalyst::Controller::REST::DBIC

[Aristotle Pagaltzis]

* Zbigniew Lukasiak <[EMAIL PROTECTED]> [2008-05-15 21:25]:
> On Thu, May 15, 2008 at 7:31 PM, Mark Trostler <[EMAIL PROTECTED]> wrote:
> > Similarly you don't need 'id' in the url - so POST to
> > /api/rest/cd will create a cd.  A PUT to /api/rest/cd/5 will
> > update that CD - a DELETE to /api/rest/cd/5 will delete that
> > CD...
> 
> Additionally we would like to have other non REST actions in
> the same controller. This mixing will require some separation
> between the method names and the object id (which is data).

You are thinking about it wrong. You don’t put method names into
the URI; you expose more of the state as things to manipulate.

If you give an example of what you mean I can give you one of
what I mean.

Regards,
-- 
Aristotle Pagaltzis // 

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Re: RFC: Catalyst::Controller::REST::DBIC

[Patrick Donelan]

The only header I've found you can't always set via xhr.setRequestHeader()
is WWW-Authenticate because the browser thinks it should be responsible for
HTTP Authentication. Which is why the last 2 optional arguments to
xhr.open() are username and password, to effectively let you set these
headers (it does the base64 encoding for you too which is handy).

If anyone manages to remember any specific browser limitations or can find
any references please let me know since it would be important for any
RESTful design.

Patrick

On Mon, May 5, 2008 at 9:34 PM, Matt S Trout <[EMAIL PROTECTED]> wrote:

> On Mon, May 05, 2008 at 10:46:56AM +0100, luke saunders wrote:
> > On Mon, May 5, 2008 at 1:20 AM, Patrick Donelan <[EMAIL PROTECTED]> wrote:
> > >
> > > > No, but how you provide an alternative to full RESTness for clients
> that
> > > > don't handle the full range of HTTP verbs -is- a matter for
> discussion.
> > > >
> > >
> > > Which clients are we talking about here? I did a quick google search
> and
> > > could only find an off-hand remark along the lines of "in 2006 safari
> had
> > > poor support for REST verbs". I'm interested because in my own
> personal
> > > experience I haven't run into any problems generating
> PUT/POST/GET/DELETE
> > > with IE/FF/Opera browsers. Or are you talking about the inability to
> specify
> > > anything other than GET or POST as a form method?
> > >
> >
> > I'm afraid I can't remember exactly, it was around two years ago and
> > we needed to fire PUT requests using XHR in JS using Dojo and it just
> > wasn't happening. Dojo has changed dramatically since then and now has
> > an xhrPut method so I expect whatever the problem has been addressed.
>
> Doubt it.
>
> The problem was the browsers gleefully threw out half the headers we were
> trying to send when we used a PUT request. Fuck all dojo can do about that
> so far as I can see.
>
> Of course I forget which browsers and which headers, but it sure as hell
> fucked our shit up but good.
>
> --
>  Matt S Trout   Need help with your Catalyst or DBIx::Class
> project?
>   Technical Director
> http://www.shadowcat.co.uk/catalyst/
>  Shadowcat Systems Ltd.  Want a managed development or deployment
> platform?
> http://chainsawblues.vox.com/
> http://www.shadowcat.co.uk/servers/
>
> ___
> List: Catalyst@lists.scsys.co.uk
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive:
> http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
> Dev site: http://dev.catalyst.perl.org/
>
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Re: RFC: Catalyst::Controller::REST::DBIC

[Matt S Trout]

On Mon, May 05, 2008 at 10:46:56AM +0100, luke saunders wrote:
> On Mon, May 5, 2008 at 1:20 AM, Patrick Donelan <[EMAIL PROTECTED]> wrote:
> >
> > > No, but how you provide an alternative to full RESTness for clients that
> > > don't handle the full range of HTTP verbs -is- a matter for discussion.
> > >
> >
> > Which clients are we talking about here? I did a quick google search and
> > could only find an off-hand remark along the lines of "in 2006 safari had
> > poor support for REST verbs". I'm interested because in my own personal
> > experience I haven't run into any problems generating PUT/POST/GET/DELETE
> > with IE/FF/Opera browsers. Or are you talking about the inability to specify
> > anything other than GET or POST as a form method?
> >
> 
> I'm afraid I can't remember exactly, it was around two years ago and
> we needed to fire PUT requests using XHR in JS using Dojo and it just
> wasn't happening. Dojo has changed dramatically since then and now has
> an xhrPut method so I expect whatever the problem has been addressed.

Doubt it.

The problem was the browsers gleefully threw out half the headers we were
trying to send when we used a PUT request. Fuck all dojo can do about that
so far as I can see.

Of course I forget which browsers and which headers, but it sure as hell
fucked our shit up but good.

-- 
  Matt S Trout   Need help with your Catalyst or DBIx::Class project?
   Technical Directorhttp://www.shadowcat.co.uk/catalyst/
 Shadowcat Systems Ltd.  Want a managed development or deployment platform?
http://chainsawblues.vox.com/http://www.shadowcat.co.uk/servers/

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Re: RFC: Catalyst::Controller::REST::DBIC

[luke saunders]

On Mon, May 5, 2008 at 1:20 AM, Patrick Donelan <[EMAIL PROTECTED]> wrote:
>
> > No, but how you provide an alternative to full RESTness for clients that
> > don't handle the full range of HTTP verbs -is- a matter for discussion.
> >
>
> Which clients are we talking about here? I did a quick google search and
> could only find an off-hand remark along the lines of "in 2006 safari had
> poor support for REST verbs". I'm interested because in my own personal
> experience I haven't run into any problems generating PUT/POST/GET/DELETE
> with IE/FF/Opera browsers. Or are you talking about the inability to specify
> anything other than GET or POST as a form method?
>

I'm afraid I can't remember exactly, it was around two years ago and
we needed to fire PUT requests using XHR in JS using Dojo and it just
wasn't happening. Dojo has changed dramatically since then and now has
an xhrPut method so I expect whatever the problem has been addressed.

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

[Catalyst] Re: RFC: Catalyst::Controller::REST::DBIC

[Aristotle Pagaltzis]

* Matt S Trout <[EMAIL PROTECTED]> [2008-05-04 16:25]:
> On Sun, May 04, 2008 at 09:10:56AM +0200, Aristotle Pagaltzis wrote:
> > * luke saunders <[EMAIL PROTECTED]> [2008-05-04 02:50]:
> > > Also it doesn't distinguish between POST, PUT, DELETE and
> > > GET HTTP requests favouring instead entirely separate
> > > endpoints, but that's up for discussion.
> > 
> > Putting the verb in the URI is RPC, not REST. This is not a
> > matter of discussion.
> 
> No, but how you provide an alternative to full RESTness for
> clients that don't handle the full range of HTTP verbs -is- a
> matter for discussion.
> 
> Or at least a matter for determining an architecture that
> allows you to use whatever alternative you like.
> 
> Please don't let your obsessive REST advocacy blind you to
> pragmatic software development issues; it's starting to get
> boring.

You are reading things into my post that aren’t there. I made a
statement of fact about what REST is; there was no advocacy
either way in it.

Still, since you mention pragmatism, let me point out that I do
not consider purely RESTful design an an ivory-tower pursuit; it
has practical benefits, and if you understand what REST is and
don’t dismiss the idea of complying with it out of hand, it’s not
hard to come up with workarounds for limited clients, such as the
excellent Catalyst::Request::REST::ForBrowsers.

I have been thinking about changes I’d like to propose to
Catalyst::Action::REST to make it less verbose in some
circumstances, and I have some half-baked ideas regarding
emulation of HTTP Auth using cookies. When I’m done I want to tie
all this together by way of a controller base class. If anyone is
thinking along the same lines, I shall be happy to talk in
private, but before I run my mouth off too much in public I want
to have code to show.

None of this, btw, is specific to a CRUD interface, but could be
a great foundation to build one with.

Regards,
-- 
Aristotle Pagaltzis // 

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Re: RFC: Catalyst::Controller::REST::DBIC

[Patrick Donelan]

>
> No, but how you provide an alternative to full RESTness for clients that
> don't handle the full range of HTTP verbs -is- a matter for discussion.
>

Which clients are we talking about here? I did a quick google search and
could only find an off-hand remark along the lines of "in 2006 safari had
poor support for REST verbs". I'm interested because in my own personal
experience I haven't run into any problems generating PUT/POST/GET/DELETE
with IE/FF/Opera browsers. Or are you talking about the inability to specify
anything other than GET or POST as a form method?

Patrick
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Re: RFC: Catalyst::Controller::REST::DBIC

[J. Shirley]

On Sun, May 4, 2008 at 7:15 AM, Matt S Trout <[EMAIL PROTECTED]> wrote:
> On Sun, May 04, 2008 at 09:10:56AM +0200, Aristotle Pagaltzis wrote:
>  > * luke saunders <[EMAIL PROTECTED]> [2008-05-04 02:50]:
>  > > Also it doesn't distinguish between POST, PUT, DELETE and GET
>  > > HTTP requests favouring instead entirely separate endpoints,
>  > > but that's up for discussion.
>  >
>  > Putting the verb in the URI is RPC, not REST. This is not a
>  > matter of discussion.
>
>  No, but how you provide an alternative to full RESTness for clients that
>  don't handle the full range of HTTP verbs -is- a matter for discussion.
>
>  Or at least a matter for determining an architecture that allows you to
>  use whatever alternative you like.
>
>  Please don't let your obsessive REST advocacy blind you to pragmatic
>  software development issues; it's starting to get boring.
>

Naming things REST when they aren't confuses the namespace and further
propagates the confusion about what REST actually is.  Call it
something else and do everybody who actually tries to build RESTful
apps a favor.  Trying to argue in favor of naming something that isn't
REST in any way REST does a disservice to the world.  And kills
puppies, deprives worthy little girls of ponies, elects
neoconservatives to office and, quite possibly, lights a bag of
excrement on your porch then ringing your doorbell and running.

And, on a more topical note, my method for having actual REST and then
a dumbed down browser version is similar to jrockway's suggestion
about dispatch methods.  My approach is a set of very thin actions
that exist outside of the main API space (or, what I've been playing
around with is a more adaptive interface based on what Dave Rolsky is
working on: 
http://search.cpan.org/~drolsky/Catalyst-Request-REST-ForBrowsers-0.01/lib/Catalyst/Request/REST/ForBrowsers.pm).
 They really end up just being a sort of internal API to the base web
service.  This also addresses the id == primary key issue, because in
your front-end browser-facing scheme, you have /book/id/{primary key},
which maps to /book/{unique identifier}.

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Re: RFC: Catalyst::Controller::REST::DBIC

[Matt S Trout]

On Sun, May 04, 2008 at 09:10:56AM +0200, Aristotle Pagaltzis wrote:
> * luke saunders <[EMAIL PROTECTED]> [2008-05-04 02:50]:
> > Also it doesn't distinguish between POST, PUT, DELETE and GET
> > HTTP requests favouring instead entirely separate endpoints,
> > but that's up for discussion.
> 
> Putting the verb in the URI is RPC, not REST. This is not a
> matter of discussion.

No, but how you provide an alternative to full RESTness for clients that
don't handle the full range of HTTP verbs -is- a matter for discussion.

Or at least a matter for determining an architecture that allows you to
use whatever alternative you like.

Please don't let your obsessive REST advocacy blind you to pragmatic
software development issues; it's starting to get boring.

-- 
  Matt S Trout   Need help with your Catalyst or DBIx::Class project?
   Technical Directorhttp://www.shadowcat.co.uk/catalyst/
 Shadowcat Systems Ltd.  Want a managed development or deployment platform?
http://chainsawblues.vox.com/http://www.shadowcat.co.uk/servers/

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

[Catalyst] Re: RFC: Catalyst::Controller::REST::DBIC

[Aristotle Pagaltzis]

* luke saunders <[EMAIL PROTECTED]> [2008-05-04 02:50]:
> Also it doesn't distinguish between POST, PUT, DELETE and GET
> HTTP requests favouring instead entirely separate endpoints,
> but that's up for discussion.

Putting the verb in the URI is RPC, not REST. This is not a
matter of discussion.

Regards,
-- 
Aristotle Pagaltzis // 

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/