tag:blogger.com,1999:blog-6301633.post112776092067223272..comments2023-08-17T02:38:45.068-05:00Comments on Messages not Models: Technorati. Sigh.hughwhttp://www.blogger.com/profile/04766131116514643236noreply@blogger.comBlogger3125tag:blogger.com,1999:blog-6301633.post-1127782285331234892005-09-26T19:51:00.000-05:002005-09-26T19:51:00.000-05:00Got it, guys. I knew in my bones it was wrong. Jus...Got it, guys. I knew in my bones it was wrong. Just can't read a spec.hughwhttps://www.blogger.com/profile/04766131116514643236noreply@blogger.comtag:blogger.com,1999:blog-6301633.post-1127770524035921372005-09-26T16:35:00.001-05:002005-09-26T16:35:00.001-05:00You've described idempotency, actually. HTTP does...You've described idempotency, actually. HTTP does require that GET is <B>safe</B> as well. Specifically, that the user is intending and aware that the effects will occur when the GET is done. Watchlist modification is not in that camp.<BR/><BR/>WRT to the RESTfulness of the URI, it's up to the server to define the authority of the URIs they generate... so who can complain? :)<BR/><BR/>-- <BR/>...jsled<BR/>http://asynchronous.org/jsledAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-6301633.post-1127770506184651522005-09-26T16:35:00.000-05:002005-09-26T16:35:00.000-05:00You were right to begin with; it's bad for GET to ...You were right to begin with; it's bad for GET to have a state-changing result like the one you describe (i.e. one whereby the responsibility of the change falls on you). See section 9.1.1 of RFC 2616 instead of 9.1.2.Mark Bakerhttps://www.blogger.com/profile/16022286854298333833noreply@blogger.com