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 so
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 br
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
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 on
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
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 ha
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
* 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
th
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 wi
* 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/re
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 (i
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
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
* 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 entirel
>
> 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 ha
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 favou
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.
>
> Pu
* 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.
18 matches
Mail list logo
