rest-discuss : Messages : 17979-17992 of 19451

#17979

From: Ramamoorthy Subramanian <ramsub4@...>
Date: Thu Dec 1, 2011 2:16 am
Subject: Defining REST for maintenance operations

ramsub4

Send Email

Hi,

While we can use REST for CRUD operations, I wonder how it can be used for
maintenance operations such as Backup/Restore and Upgrade. These are time
consuming operations and some of us our team members are suggesting to use SOAP
for these. Have two questions.

1. Can we use REST for these maintenance operations? If so, can you let me know
pointers of examples?
2. If SOAP is better fit, is that OK to hybrid web services implementation
supporting both REST and SOAP? Wouldn't this confuse/complicate client
developers?

Thanks,

-rama

#17980

From: mike amundsen <mamund@...>
Date: Thu Dec 1, 2011 3:03 am
Subject: Re: Defining REST for maintenance operations

mamund

Send Email

rama:

HTTP has good support for dealing with long-running operations.�upon receiving a client's request to start a long-running operation, the server can�return 202 (Accepted) along w/ a �URI that points to a resource that represents the progress of the work. this response can also include hints on how long to wait before hitting this URI. this is a shots, simple request/response interaction that need not leave any open connection between client and server.

*** REQUEST

POST /long-running-jobs/

....

*** RESPONSE

202 Accepted

...

<a href="..." rel="progress">check on progress</a>

each request to this returned URI could show progress information and, eventually the details of success or failure. success may include a pointer to the _final_ URI of the completed work.�you can use this pattern to create logs and other audit information about the long-running process. you can expose a single resource that lists all the outstanding long-running processes; filters out the failures, etc. etc.

i work w/ a number of clients that use this pattern for handling requests to do post-processing work on uploaded data.

�

mca
http://amundsen.com/blog/
http://twitter.com@mamund
http://mamund.com/foaf.rdf#me

On Wed, Nov 30, 2011 at 21:16, Ramamoorthy Subramanian <ramsub4@...> wrote:

Hi,

While we can use REST for CRUD operations, I wonder how it can be used for
maintenance operations such as Backup/Restore and Upgrade. These are time
consuming operations and some of us our team members are suggesting to use SOAP
for these. Have two questions.

1. Can we use REST for these maintenance operations? If so, can you let me know
pointers of examples?
2. If SOAP is better fit, is that OK to hybrid web services implementation
supporting both REST and SOAP? Wouldn't this confuse/complicate client
developers?

Thanks,

-rama

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
� �http://groups.yahoo.com/group/rest-discuss/

<*> Your email settings:
� �Individual Email | Traditional

<*> To change settings online go to:
� �http://groups.yahoo.com/group/rest-discuss/join
� �(Yahoo! ID required)

<*> To change settings via email:
� �rest-discuss-digest@yahoogroups.com
� �rest-discuss-fullfeatured@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
� �rest-discuss-unsubscribe@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
� �http://docs.yahoo.com/info/terms/

#17988

From: Ramamoorthy Subramanian <ramsub4@...>
Date: Thu Dec 1, 2011 6:00 pm
Subject: Re: Defining REST for maintenance operations

ramsub4

Send Email

Thanks Mike. This idea makes perfect sense.

Btw, is it a good idea doing asynchronous notification for such a long-running operation? This way, the client need not poll for the completion of operation. Thanks.

-rama

From: mike amundsen <mamund@...>
To: Ramamoorthy Subramanian <ramsub4@...>
Cc: rest-discuss@yahoogroups.com
Sent: Thu, December 1, 2011 8:33:56 AM
Subject: Re: [rest-discuss] Defining REST for maintenance operations

rama:

HTTP has good support for dealing with long-running operations. upon receiving a client's request to start a long-running operation, the server can return 202 (Accepted) along w/ a URI that points to a resource that represents the progress of the work. this response can also include hints on how long to wait before hitting this URI. this is a shots, simple request/response interaction that need not leave any open connection between client and server.

*** REQUEST

POST /long-running-jobs/

....

*** RESPONSE

202 Accepted

...

<a href="..." rel="progress">check on progress</a>

each request to this returned URI could show progress information and, eventually the details of success or failure. success may include a pointer to the _final_ URI of the completed work. you can use this pattern to create logs and other audit information about the long-running process. you can expose a single resource that lists all the outstanding long-running processes; filters out the failures, etc. etc.

i work w/ a number of clients that use this pattern for handling requests to do post-processing work on uploaded data.

mca
http://amundsen.com/blog/
http://twitter.com@mamund
http://mamund.com/foaf.rdf#me

On Wed, Nov 30, 2011 at 21:16, Ramamoorthy Subramanian <ramsub4@...> wrote:

Hi,

While we can use REST for CRUD operations, I wonder how it can be used for
maintenance operations such as Backup/Restore and Upgrade. These are time
consuming operations and some of us our team members are suggesting to use SOAP
for these. Have two questions.

1. Can we use REST for these maintenance operations? If so, can you let me know
pointers of examples?
2. If SOAP is better fit, is that OK to hybrid web services implementation
supporting both REST and SOAP? Wouldn't this confuse/complicate client
developers?

Thanks,

-rama

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/rest-discuss/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/rest-discuss/join
(Yahoo! ID required)

<*> To change settings via email:
rest-discuss-digest@yahoogroups.com
rest-discuss-fullfeatured@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
rest-discuss-unsubscribe@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

#17989

From: mike amundsen <mamund@...>
Date: Thu Dec 1, 2011 6:06 pm
Subject: Re: Defining REST for maintenance operations

mamund

Send Email

Rama:

since HTTP is a Client-Server protocol, it's most effective when you allow clients to initiate�conversations. There are a number of ways to "optimize" your use case:

- for HTML, rely on the meta-refresh pattern and adjust polling times dynamically.

- for generic clients, use an explicit cache value to prevent clients from hitting the origin server

- servers can emit the Retry-After header with a timespan

Also, if it becomes an issue, servers can block responses from clients that don't honor the settings listed above in order to prevent "bad actors" from flooding the system

There are callback libraries that work over HTTP using long-poling, etc. but i do not find they are reliable, scalable, or any more effective than the suggestions here.

mca
http://amundsen.com/blog/
http://twitter.com@mamund
http://mamund.com/foaf.rdf#me

On Thu, Dec 1, 2011 at 13:00, Ramamoorthy Subramanian <ramsub4@...> wrote:

Thanks Mike. This idea makes perfect sense.

Btw, is it a good idea doing asynchronous notification for such a long-running operation? This way, the client need not poll for the completion of operation. Thanks.

-rama

From: mike amundsen <mamund@...>
To: Ramamoorthy Subramanian <ramsub4@...>
Cc: rest-discuss@yahoogroups.com
Sent: Thu, December 1, 2011 8:33:56 AM
Subject: Re: [rest-discuss] Defining REST for maintenance operations

�

rama:

HTTP has good support for dealing with long-running operations.�upon receiving a client's request to start a long-running operation, the server can�return 202 (Accepted) along w/ a �URI that points to a resource that represents the progress of the work. this response can also include hints on how long to wait before hitting this URI. this is a shots, simple request/response interaction that need not leave any open connection between client and server.

*** REQUEST
POST /long-running-jobs/
....

*** RESPONSE
202 Accepted
...
<a href="..." rel="progress">check on progress</a>

each request to this returned URI could show progress information and, eventually the details of success or failure. success may include a pointer to the _final_ URI of the completed work.�you can use this pattern to create logs and other audit information about the long-running process. you can expose a single resource that lists all the outstanding long-running processes; filters out the failures, etc. etc.

i work w/ a number of clients that use this pattern for handling requests to do post-processing work on uploaded data.
�

mca
http://amundsen.com/blog/
http://twitter.com@mamund
http://mamund.com/foaf.rdf#me

On Wed, Nov 30, 2011 at 21:16, Ramamoorthy Subramanian <ramsub4@...> wrote:
Hi,

While we can use REST for CRUD operations, I wonder how it can be used for
maintenance operations such as Backup/Restore and Upgrade. These are time
consuming operations and some of us our team members are suggesting to use SOAP
for these. Have two questions.

1. Can we use REST for these maintenance operations? If so, can you let me know
pointers of examples?
2. If SOAP is better fit, is that OK to hybrid web services implementation
supporting both REST and SOAP? Wouldn't this confuse/complicate client
developers?

Thanks,

-rama

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
� �http://groups.yahoo.com/group/rest-discuss/

<*> Your email settings:
� �Individual Email | Traditional

<*> To change settings online go to:
� �http://groups.yahoo.com/group/rest-discuss/join
� �(Yahoo! ID required)

<*> To change settings via email:
� �rest-discuss-digest@yahoogroups.com
� �rest-discuss-fullfeatured@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
� �rest-discuss-unsubscribe@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
� �http://docs.yahoo.com/info/terms/

#17990

From: Ramamoorthy Subramanian <ramsub4@...>
Date: Thu Dec 1, 2011 6:08 pm
Subject: Re: Defining REST for maintenance operations

ramsub4

Send Email

Thanks Mike. You mean, technologies such as Comet wont be reliable?

-rama

From: mike amundsen <mamund@...>
To: Ramamoorthy Subramanian <ramsub4@...>
Cc: rest-discuss@yahoogroups.com
Sent: Thu, December 1, 2011 11:36:20 PM
Subject: Re: [rest-discuss] Defining REST for maintenance operations

Rama:

since HTTP is a Client-Server protocol, it's most effective when you allow clients to initiate conversations. There are a number of ways to "optimize" your use case:

- for HTML, rely on the meta-refresh pattern and adjust polling times dynamically.

- for generic clients, use an explicit cache value to prevent clients from hitting the origin server

- servers can emit the Retry-After header with a timespan

Also, if it becomes an issue, servers can block responses from clients that don't honor the settings listed above in order to prevent "bad actors" from flooding the system

There are callback libraries that work over HTTP using long-poling, etc. but i do not find they are reliable, scalable, or any more effective than the suggestions here.

mca
http://amundsen.com/blog/
http://twitter.com@mamund
http://mamund.com/foaf.rdf#me

On Thu, Dec 1, 2011 at 13:00, Ramamoorthy Subramanian <ramsub4@...> wrote:

Thanks Mike. This idea makes perfect sense.

Btw, is it a good idea doing asynchronous notification for such a long-running operation? This way, the client need not poll for the completion of operation. Thanks.

-rama

From: mike amundsen <mamund@...>
To: Ramamoorthy Subramanian <ramsub4@...>
Cc: rest-discuss@yahoogroups.com
Sent: Thu, December 1, 2011 8:33:56 AM
Subject: Re: [rest-discuss] Defining REST for maintenance operations

rama:

HTTP has good support for dealing with long-running operations. upon receiving a client's request to start a long-running operation, the server can return 202 (Accepted) along w/ a URI that points to a resource that represents the progress of the work. this response can also include hints on how long to wait before hitting this URI. this is a shots, simple request/response interaction that need not leave any open connection between client and server.

*** REQUEST
POST /long-running-jobs/
....

*** RESPONSE
202 Accepted
...
<a href="..." rel="progress">check on progress</a>

each request to this returned URI could show progress information and, eventually the details of success or failure. success may include a pointer to the _final_ URI of the completed work. you can use this pattern to create logs and other audit information about the long-running process. you can expose a single resource that lists all the outstanding long-running processes; filters out the failures, etc. etc.

i work w/ a number of clients that use this pattern for handling requests to do post-processing work on uploaded data.

mca
http://amundsen.com/blog/
http://twitter.com@mamund
http://mamund.com/foaf.rdf#me

On Wed, Nov 30, 2011 at 21:16, Ramamoorthy Subramanian <ramsub4@...> wrote:
Hi,

While we can use REST for CRUD operations, I wonder how it can be used for
maintenance operations such as Backup/Restore and Upgrade. These are time
consuming operations and some of us our team members are suggesting to use SOAP
for these. Have two questions.

1. Can we use REST for these maintenance operations? If so, can you let me know
pointers of examples?
2. If SOAP is better fit, is that OK to hybrid web services implementation
supporting both REST and SOAP? Wouldn't this confuse/complicate client
developers?

Thanks,

-rama

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/rest-discuss/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/rest-discuss/join
(Yahoo! ID required)

<*> To change settings via email:
rest-discuss-digest@yahoogroups.com
rest-discuss-fullfeatured@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
rest-discuss-unsubscribe@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

#17991

From: mike amundsen <mamund@...>
Date: Thu Dec 1, 2011 6:13 pm
Subject: Re: Defining REST for maintenance operations

mamund

Send Email

i meant to say i don't find using Comet (and other similar approaches) any more reliable, scale-able, effective than HTTP's Client-Server centered options.

This is a personal choice based on my own experience.

Others on this list may have experience w/ Comet, etc. that they can share.

�
mca
http://amundsen.com/blog/
http://twitter.com@mamund
http://mamund.com/foaf.rdf#me

On Thu, Dec 1, 2011 at 13:08, Ramamoorthy Subramanian <ramsub4@...> wrote:

Thanks Mike. You mean, technologies such as Comet wont be reliable?

-rama

From: mike amundsen <mamund@...>
To: Ramamoorthy Subramanian <ramsub4@...>
Cc: rest-discuss@yahoogroups.com
Sent: Thu, December 1, 2011 11:36:20 PM

Subject: Re: [rest-discuss] Defining REST for maintenance operations

Rama:

since HTTP is a Client-Server protocol, it's most effective when you allow clients to initiate�conversations. There are a number of ways to "optimize" your use case:

- for HTML, rely on the meta-refresh pattern and adjust polling times dynamically.

- for generic clients, use an explicit cache value to prevent clients from hitting the origin server

- servers can emit the Retry-After header with a timespan

Also, if it becomes an issue, servers can block responses from clients that don't honor the settings listed above in order to prevent "bad actors" from flooding the system

There are callback libraries that work over HTTP using long-poling, etc. but i do not find they are reliable, scalable, or any more effective than the suggestions here.

mca
http://amundsen.com/blog/
http://twitter.com@mamund
http://mamund.com/foaf.rdf#me

On Thu, Dec 1, 2011 at 13:00, Ramamoorthy Subramanian <ramsub4@...> wrote:

Thanks Mike. This idea makes perfect sense.

Btw, is it a good idea doing asynchronous notification for such a long-running operation? This way, the client need not poll for the completion of operation. Thanks.

-rama

From: mike amundsen <mamund@...>
To: Ramamoorthy Subramanian <ramsub4@...>
Cc: rest-discuss@yahoogroups.com
Sent: Thu, December 1, 2011 8:33:56 AM
Subject: Re: [rest-discuss] Defining REST for maintenance operations

�

rama:

HTTP has good support for dealing with long-running operations.�upon receiving a client's request to start a long-running operation, the server can�return 202 (Accepted) along w/ a �URI that points to a resource that represents the progress of the work. this response can also include hints on how long to wait before hitting this URI. this is a shots, simple request/response interaction that need not leave any open connection between client and server.

*** REQUEST
POST /long-running-jobs/
....

*** RESPONSE
202 Accepted
...
<a href="..." rel="progress">check on progress</a>

each request to this returned URI could show progress information and, eventually the details of success or failure. success may include a pointer to the _final_ URI of the completed work.�you can use this pattern to create logs and other audit information about the long-running process. you can expose a single resource that lists all the outstanding long-running processes; filters out the failures, etc. etc.

i work w/ a number of clients that use this pattern for handling requests to do post-processing work on uploaded data.
�

mca
http://amundsen.com/blog/
http://twitter.com@mamund
http://mamund.com/foaf.rdf#me

On Wed, Nov 30, 2011 at 21:16, Ramamoorthy Subramanian <ramsub4@...> wrote:
Hi,

While we can use REST for CRUD operations, I wonder how it can be used for
maintenance operations such as Backup/Restore and Upgrade. These are time
consuming operations and some of us our team members are suggesting to use SOAP
for these. Have two questions.

1. Can we use REST for these maintenance operations? If so, can you let me know
pointers of examples?
2. If SOAP is better fit, is that OK to hybrid web services implementation
supporting both REST and SOAP? Wouldn't this confuse/complicate client
developers?

Thanks,

-rama

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
� �http://groups.yahoo.com/group/rest-discuss/

<*> Your email settings:
� �Individual Email | Traditional

<*> To change settings online go to:
� �http://groups.yahoo.com/group/rest-discuss/join
� �(Yahoo! ID required)

<*> To change settings via email:
� �rest-discuss-digest@yahoogroups.com
� �rest-discuss-fullfeatured@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
� �rest-discuss-unsubscribe@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
� �http://docs.yahoo.com/info/terms/

#17992

From: Erik Wilde <dret@...>
Date: Thu Dec 1, 2011 7:39 pm
Subject: Re: Defining REST for maintenance operations

drethoo

Send Email

hello rama.

On 2011-12-01 10:00 , Ramamoorthy Subramanian wrote:
> Btw, is it a good idea doing asynchronous notification for such a
> long-running operation? This way, the client need not poll for the
> completion of operation. Thanks.

http://dret.net/netdret/publications#pau11b (to be presented next week
at ICSOC by cesare pautasso) might give you some ideas about how you
could do that in a RESTful way. basically, the idea is to allow clients
to subscribe to updates about change notifications.

kind regards,

dret.

--
erik wilde | mailto:dret@...  -  tel:+1-510-2061079 |
             | UC Berkeley  -  School of Information (ISchool) |
             | http://dret.net/netdret http://twitter.com/dret |

< Prev Topic | Next Topic >

Yahoo! Groups

Breaking News Visit Yahoo! News for the latest.

The Yahoo! Groups Product Blog

Check it out!

Group Information

Yahoo! Groups Tips

Did you know...

Messages