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