Feedback on the Pub/Sub sample

[Paul Sandoz]

Hi,

http://weblogs.java.net/blog/jfarcand/archive/2009/11/03/writing-restful-and-comet-based-pubsub-application-using-atmosphere

I think from a "RESTy" type perspective (of course because of Comet we  
not conforming to REST) it would be more appropriate to do:

     @Path("/{topic}")
     @Broadcast @POST
     @Consumes("application/x-www-form-urlencoded")
     public Broadcastable publish(
              @PathParam("topic") Broadcaster topic,
              @FormParam("message") String message){
         return new Broadcastable(message,topic);
     }

Because in the example the GET has side effects (keep repeating it and  
a message is sent every time). Using POST is still easy with curl:

   curl -D message="Atmosphere+is+cool" \
     http://localhost:8080/atmosphere-pubsub/myAtmosphereTopic

Also the @Produces("text/txt;charset=ISO-8859-1") looks incorrect, do  
you mean text/plain?

I am sort of wondering if we should enforce that @Broadcast should  
only work with @POST. But perhaps that is going too far.

Also wondering the following: imagine if on the GET to http://localhost:8080/atmosphere-pubsub 
  it returned some XML or JSON with link:

   <link
     template="http://localhost:8080/atmosphere-pubsub/myAtmosphereTopic/ 
{topic}"
     rel="suspend, broadcast">

The "rel" attribute value says if you do a GET you suspend and if you  
do a POST you broadcast.

That type of thing might actual be possible to automate. In addition  
it might be possible to embed such data in the WADL returned by OPTIONS.

Paul.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Jeanfrancois Arcand]

Salut,

Paul Sandoz wrote:

> Hi,
>
> http://weblogs.java.net/blog/jfarcand/archive/2009/11/03/writing-restful-and-comet-based-pubsub-application-using-atmosphere 
>
>
> I think from a "RESTy" type perspective (of course because of Comet we
> not conforming to REST) it would be more appropriate to do:
>
>     @Path("/{topic}")
>     @Broadcast @POST
>     @Consumes("application/x-www-form-urlencoded")
>     public Broadcastable publish(
>              @PathParam("topic") Broadcaster topic,
>              @FormParam("message") String message){
>         return new Broadcastable(message,topic);
>     }
>
> Because in the example the GET has side effects (keep repeating it and a
> message is sent every time). Using POST is still easy with curl:
>
>   curl -D message="Atmosphere+is+cool" \
>     http://localhost:8080/atmosphere-pubsub/myAtmosphereTopic

Actually my first version was using POST, but I tough it was clearer
with GET. Seems not :-). Felipe (cc-ed) also commented:

"> Just a tip my friend: if you call an application RESTful and use GET
to create resources, the REST community will blame you :) eheh Don't ask
me, I am another Java developer thinking in terms of objects and method
calls, but people outside the Java universe are not so friendly when we
abuse their rules :) I learned this in the hard way, so I hope my hint
can avoid some flames to you ... (ops, I just started one :)"

I admit I wasn't aware of that...


>
> Also the @Produces("text/txt;charset=ISO-8859-1") looks incorrect, do
> you mean text/plain?

Ya typo....


>
> I am sort of wondering if we should enforce that @Broadcast should only
> work with @POST. But perhaps that is going too far.

I think so too. Usually you will use a GET to suspend a connection, and
you might want to broadcast some events.

>
> Also wondering the following: imagine if on the GET to
> http://localhost:8080/atmosphere-pubsub it returned some XML or JSON
> with link:
>
>   <link
>    
> template="http://localhost:8080/atmosphere-pubsub/myAtmosphereTopic/{topic}"
>
>     rel="suspend, broadcast">
>
> The "rel" attribute value says if you do a GET you suspend and if you do
> a POST you broadcast.
>
> That type of thing might actual be possible to automate. In addition it
> might be possible to embed such data in the WADL returned by OPTIONS.

That sound interesting....I need to deep dive a little more into WADL
before I can be sure it will work :-)

A+

-- Jeanfrancois


>
> Paul.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Paul Sandoz]

Some javascript/style in this post has been disabled (why?)

On Nov 4, 2009, at 4:49 PM, Jeanfrancois Arcand wrote:

I am sort of wondering if we should enforce that @Broadcast should only work with @POST. But perhaps that is going too far.

I think so too. Usually you will use a GET to suspend a connection, and you might want to broadcast some events.

OK. I can definitely see the case for suspend on POST if some initial data needs to be sent.

Also wondering the following: imagine if on the GET to http://localhost:8080/atmosphere-pubsub it returned some XML or JSON with link:

 <link

   template="http://localhost:8080/atmosphere-pubsub/myAtmosphereTopic/{topic}"     rel="suspend, broadcast">

The "rel" attribute value says if you do a GET you suspend and if you do a POST you broadcast.

That type of thing might actual be possible to automate. In addition it might be possible to embed such data in the WADL returned by OPTIONS.

That sound interesting....I need to deep dive a little more into WADL before I can be sure it will work :-)

I am compressing two different ideas :-) one providing some common rules/patterns for self-describing suspend/broadcast/resume link types, and the other allowing that self-description to be auto-generated for a GET or embedded WADL.

Paul.

[Jeanfrancois Arcand]

Salut,

Paul Sandoz wrote:

> On Nov 4, 2009, at 4:49 PM, Jeanfrancois Arcand wrote:
>>
>>> I am sort of wondering if we should enforce that @Broadcast should
>>> only work with @POST. But perhaps that is going too far.
>>
>> I think so too. Usually you will use a GET to suspend a connection,
>> and you might want to broadcast some events.
>>
>
> OK. I can definitely see the case for suspend on POST if some initial
> data needs to be sent.

I think we should not restrict based on a Method, but recommend using
POST but allow other as well. Comet and specially with Jersey is so new
I would like to grab more real use case before taking a decision.

>
>
>>
>>> Also wondering the following: imagine if on the GET to
>>> http://localhost:8080/atmosphere-pubsub it returned some XML or JSON
>>> with link:
>>>  <link
>>>    template="http://localhost:8080/atmosphere-pubsub/myAtmosphereTopic/{topic}"
>>>     rel="suspend, broadcast">
>>> The "rel" attribute value says if you do a GET you suspend and if you
>>> do a POST you broadcast.
>>> That type of thing might actual be possible to automate. In addition
>>> it might be possible to embed such data in the WADL returned by OPTIONS.
>>
>> That sound interesting....I need to deep dive a little more into WADL
>> before I can be sure it will work :-)
>>
>
> I am compressing two different ideas :-) one providing some common
> rules/patterns for self-describing suspend/broadcast/resume link types,
> and the other allowing that self-description to be auto-generated for a
> GET or embedded WADL.

Thanks for the explanation :-) I admit I have some catch up on that area...

A+

-- Jeanfrancois


>
> Paul.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Paul Sandoz]

On Nov 4, 2009, at 6:08 PM, Jeanfrancois Arcand wrote:

>
> Salut,
>
> Paul Sandoz wrote:
>> On Nov 4, 2009, at 4:49 PM, Jeanfrancois Arcand wrote:
>>>
>>>> I am sort of wondering if we should enforce that @Broadcast  
>>>> should only work with @POST. But perhaps that is going too far.
>>>
>>> I think so too. Usually you will use a GET to suspend a  
>>> connection, and you might want to broadcast some events.
>>>
>> OK. I can definitely see the case for suspend on POST if some  
>> initial data needs to be sent.
>
> I think we should not restrict based on a Method, but recommend  
> using POST but allow other as well. Comet and specially with Jersey  
> is so new I would like to grab more real use case before taking a  
> decision.
>

Agreed, i think we should propose recommend patterns of use rather  
than making absolute restrictions.

Paul.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]