I also tought about this "proxy webapp" as solution, but i am not sure
if doing that i will remai hateoas... At the end you have a state
change promoted by a GET method :)
Other option perhaps better is to use the resource life-cycle to
preserve the hateoas, maling the uri visible only after the click....
Then, the GET request will always respond with a same content ...
I prefer the rest masters to contribute with hints... Let's see...
On 26.09.2009, at 20:34, "Markus KARG" <markus.karg_at_gmx.net> wrote:
> Well, you need to distinguish between a RESTful solution and
> technicals
> constraints: A RESTful solution would be to send a http PUT or POST.
> The
> fact that you cannot send a PUT or POST using a HTML link is not a
> drawback
> of REST but a technical constraint of the solution you like to have
> (enforcing the use of eMail client and browser which both is for
> man2machine
> communication, while REST is for WebServices and a WebService is for
> machine2machine communication...). Or in other words: The problem is
> not the
> technology but your fixed constraints. There is a RESTful solution to
> authentication. But there is no RESTful solution to your fixed
> constraints.
> So you need to do tricks... SMTP would be one trick which you do not
> want to
> do (actually I do not understand why -- using SMTP instead of http
> would
> result in a valid WebService with IoC behaviour actually, but
> certainly it
> is uncommon).
>
> Other tricks would be to include the PUT or POST in the HTML form
> that the
> browser will receive after the user clicked the link. I see (at
> least) two
> solutions. Solution one would be to ask the user to click a button
> in the
> web site, which in turn issues the PUT or POST using HTML <FORM>.
> Solution
> two would use JavaScript to execute the PUT or PUST as soon as the
> browser
> renders the HTML page. Both will work and will keep your WebService's
> interface clean by moving the problem into the user interface layer.
>
> HTH
> Markus
>
>> -----Original Message-----
>> From: Felipe Gaúcho [mailto:fgaucho_at_gmail.com]
>> Sent: Samstag, 26. September 2009 17:41
>> To: users_at_jersey.dev.java.net
>> Cc: rest-discuss_at_yahoogroups.com
>> Subject: Re: [Jersey] confirmation URL ? GET ?
>>
>> It seems a much more complicated solution for several reasons.. some
>> points I can remember:
>>
>> 1) The email account used by the application is write only, my rest
>> api do not receive emails ... Emails are used only to notifiy the
>> users about some event in my business scenario..
>> 2) To add a dependency to an SMTP account in my application add also
>> several corner cases to handle.. (over-engineering eventually)
>> 3) I need to parse the response emails to find the confirmation
>> token,
>> and there is no way to guarantee the user or his email client will
>> not
>> change the message format.. That's the ugly part because if
>> something
>> goes wrong here I need to create a second email and then I need to
>> establish a robust framework just to workaround issues here :)
>>
>> So, to keep it simple: any chance to use an URL confirmation and
>> still
>> remain hateoas ?
>>
>> registration is a so common scenario that I believe someone already
>> designed this before..
>>
>> * perhaps not a surprise that all popular REST services like twitter
>> has a secondary web-app to handle registration :)
>>
>>
>> On Sat, Sep 26, 2009 at 4:19 PM, Markus KARG <markus.karg_at_gmx.net>
>> wrote:
>>> Why not replacing clicking the link by just answering the email
>> (reply-to)?
>>>
>>>> -----Original Message-----
>>>> From: Felipe Gaúcho [mailto:fgaucho_at_gmail.com]
>>>> Sent: Samstag, 26. September 2009 15:48
>>>> To: rest-discuss_at_yahoogroups.com; users_at_jersey.dev.java.net
>>>> Subject: [Jersey] confirmation URL ? GET ?
>>>>
>>>> Hi there,
>>>>
>>>> my first email here...
>>>>
>>>> question: I have a registration flow that includes the following
>> steps:
>>>>
>>>> 1) client send a POST with the new user's data.
>>>> 2) the server sends an email to the new user containing a
>>>> "Confirmation URL"
>>>> 3) the user clicks on the URL, confirming his registration
>> request...
>>>>
>>>> So far so good, the basics of a registration use case.
>>>>
>>>> Now the question:
>>>>
>>>> The URL in the email should be a GET, right ? (otherwise I am not
>> sure
>>>> how it can work from an email.. )
>>>>
>>>> but, if I use GET to transform the state of a resource in the
>>>> server
>> I
>>>> am abusing the rest protocol - (GET not-idempotent since the status
>> of
>>>> the user will change from NEW to ACTIVE)
>>>>
>>>> So, what is the alternative ?
>>>>
>>>> ---
>>>> -----------------------------------------------------------------
>> -
>>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>
>>>
>>> ---
>>> ------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>
>>>
>>
>>
>>
>> --
>> Looking for a client application for this service:
>> http://fgaucho.dyndns.org:8080/arena-http/wadl
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>