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

2008-05-16 Thread 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/


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

2008-05-16 Thread 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

2008-05-16 Thread 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

2008-05-16 Thread 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

2008-05-16 Thread 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

2008-05-15 Thread 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/


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

2008-05-05 Thread 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/


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

2008-05-05 Thread 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

2008-05-05 Thread 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

2008-05-04 Thread 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/


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

2008-05-04 Thread 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/