users@jersey.java.net

RE: [Jersey] confirmation URL ? GET ?

From: Markus KARG <markus.karg_at_gmx.net>
Date: Sat, 26 Sep 2009 20:34:38 +0200

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