Citate si alte peripetii din lumea REST-ului
O noua furtuna a cuprins lumea REST-ului (si nu me refer la clasicile "why REST is better than WS-*").
Dare Obasanjo a dat tonul printr-un post in blogul sau in care demonstreaza ca Bloglines, Flickr si del.icio.us au incalcat principiile REST ce sunt expuse pe scurt aici (pentru cine nu are rabdare sa citeasca teza lui Roy Fielding). In principiu, Flickr si del.icio.us folosesc GET cand de fapt ar fi trebuit sa foloseasca DELETE, in timp ce Bloglines foloseste acelasi GET intr-o circumstanta care nu este "idempotent or safe".
A urmat articolul lui Jon Udell (titlul spune aproape totul: "End HTTP abuse"):
Why didn't Bloglines, Flickr, or del.icio.us enforce the POST restriction? I suspect it's because they wanted their APIs to have the broadest possible reach. And from a programmer's perspective, the simplest and easiest HTTP clients are those that use GET.
Concluzia lui este ca:
But if all toolkits made POST as accessible as GET -- or as nearly so as possible -- there would be less incentive to misuse GET.
La randul lui, articolul scris de Jon Udell a avut replici interesante.
Mai intai a fost Ryan Tomayko, On HTTP Abuse:
The large majority of smart technical people believe that HTTP is legacy technology: an old protocol, maybe a step above gopher, that has somehow hung around through the years. Something to be dealt with, not taken advantage of. We need to show how limiting this mind-set is.
(...)
My feeling is that we haven't done a good enough job of showing examples of what the correct use of HTTP, URIs, and XML looks like in the real world.
(...)
To sum up, we need a good implementation of HTTP/1.1 that provides a real framework for building standards based web applications. We then need to advocate and illustrate the correct use of HTTP/URIs/XML as a killer technology that has been hiding right under our noses by showing the benefits of using the system correctly.
Urmarea a venit de la Leigh Dodds, in Ending HTTP Abuse:
And yet, how many frameworks encourage or even allow the binding of handlers based on a combination of URL+method? In my experience the protocol independence anti-pattern kicks in at that point, and the request method is the last thing that a developer is encouraged to take into account. The end result are URLs that react identically to any request method. It might be an interesting experiment if Udell tried sending PUT, DELETE, HEAD requests to the same API calls.
si citatul care mi-a placut cel mai mult :) :
This situation is often compounded by URL designs that are more RPC than REST in nature. E.g. /getPerson, /updatePerson rather than just /person. In the latter case you have to use the right request method to differentiate requests and respond appropriately.
Probabil ca v-ati plictisit de atatea citate, dar din punctul meu de vedere ele arata ca lupta pentru a construi un Web 2.0 cat mai "curat" (un termen destul de vag, stiu, dar pana la urma si "vag" se potriveste perfect cu Web 2.0 :)) este in plina desfasurare si destul de incitanta.
Din pacate, in .ro disputele sterile (dupa parerea mea) in jurul unui festival de comunicare par a consuma toata energia celor ce se lupta in transeele web-developmentului, astfel incat o cautare in limba romana dupa Representational State Transfer a intors un singur rezultant relevant (ce-i drept, daca fac cautarea pentru toate site-urile .ro dau peste cateva zeci de rezultate, dar aproape toate scrise in engleza, pentru "export"). Lucrul bun este ca asa am reusit sa aflu despre acest workshop, care s-a tinut in noiembrie anul trecut (too bad I found about it only now). Totusi sper sa pot participa la editia de anul acesta (in principal daca voi avea timp, bani se gasesc intotdeauna pentru ceva ce iti place).
O sa mai scriu despre REST and stuff like this, mai ales pentru ca incerc sa fac din el "piesa de rezistenta" :) a proiectului la care lucrez acum. Acum meditez asupra dilemei "Constructing or Traversing URIs?"
Dare Obasanjo a dat tonul printr-un post in blogul sau in care demonstreaza ca Bloglines, Flickr si del.icio.us au incalcat principiile REST ce sunt expuse pe scurt aici (pentru cine nu are rabdare sa citeasca teza lui Roy Fielding). In principiu, Flickr si del.icio.us folosesc GET cand de fapt ar fi trebuit sa foloseasca DELETE, in timp ce Bloglines foloseste acelasi GET intr-o circumstanta care nu este "idempotent or safe".
A urmat articolul lui Jon Udell (titlul spune aproape totul: "End HTTP abuse"):
Why didn't Bloglines, Flickr, or del.icio.us enforce the POST restriction? I suspect it's because they wanted their APIs to have the broadest possible reach. And from a programmer's perspective, the simplest and easiest HTTP clients are those that use GET.
Concluzia lui este ca:
But if all toolkits made POST as accessible as GET -- or as nearly so as possible -- there would be less incentive to misuse GET.
La randul lui, articolul scris de Jon Udell a avut replici interesante.
Mai intai a fost Ryan Tomayko, On HTTP Abuse:
The large majority of smart technical people believe that HTTP is legacy technology: an old protocol, maybe a step above gopher, that has somehow hung around through the years. Something to be dealt with, not taken advantage of. We need to show how limiting this mind-set is.
(...)
My feeling is that we haven't done a good enough job of showing examples of what the correct use of HTTP, URIs, and XML looks like in the real world.
(...)
To sum up, we need a good implementation of HTTP/1.1 that provides a real framework for building standards based web applications. We then need to advocate and illustrate the correct use of HTTP/URIs/XML as a killer technology that has been hiding right under our noses by showing the benefits of using the system correctly.
Urmarea a venit de la Leigh Dodds, in Ending HTTP Abuse:
And yet, how many frameworks encourage or even allow the binding of handlers based on a combination of URL+method? In my experience the protocol independence anti-pattern kicks in at that point, and the request method is the last thing that a developer is encouraged to take into account. The end result are URLs that react identically to any request method. It might be an interesting experiment if Udell tried sending PUT, DELETE, HEAD requests to the same API calls.
si citatul care mi-a placut cel mai mult :) :
This situation is often compounded by URL designs that are more RPC than REST in nature. E.g. /getPerson, /updatePerson rather than just /person. In the latter case you have to use the right request method to differentiate requests and respond appropriately.
Probabil ca v-ati plictisit de atatea citate, dar din punctul meu de vedere ele arata ca lupta pentru a construi un Web 2.0 cat mai "curat" (un termen destul de vag, stiu, dar pana la urma si "vag" se potriveste perfect cu Web 2.0 :)) este in plina desfasurare si destul de incitanta.
Din pacate, in .ro disputele sterile (dupa parerea mea) in jurul unui festival de comunicare par a consuma toata energia celor ce se lupta in transeele web-developmentului, astfel incat o cautare in limba romana dupa Representational State Transfer a intors un singur rezultant relevant (ce-i drept, daca fac cautarea pentru toate site-urile .ro dau peste cateva zeci de rezultate, dar aproape toate scrise in engleza, pentru "export"). Lucrul bun este ca asa am reusit sa aflu despre acest workshop, care s-a tinut in noiembrie anul trecut (too bad I found about it only now). Totusi sper sa pot participa la editia de anul acesta (in principal daca voi avea timp, bani se gasesc intotdeauna pentru ceva ce iti place).
O sa mai scriu despre REST and stuff like this, mai ales pentru ca incerc sa fac din el "piesa de rezistenta" :) a proiectului la care lucrez acum. Acum meditez asupra dilemei "Constructing or Traversing URIs?"
posted by mihai turcu at 1:17 AM
0 Comments:
Post a Comment
<< Home