Where REST may not always be a good fit
![joe-mckendrick.jpg](https://www.zdnet.com/a/img/resize/3a9e2a2508b774d727021d3ab7170658c00cfa84/2020/01/11/aadf959a-c685-4b4b-b144-e92dc3ac4cae/joe-mckendrick.jpg?auto=webp&fit=crop&frame=1&height=192&width=192)
"For all its goodness, REST sometimes feels like trying to fit a square peg in the proverbial round hole. Some interaction patterns just don’t lend themselves well to the REST approach.... With WS-*, on the other hand, we get a square peg to fit in a square hole. The problem there is that the peg is twice as wide as the hole."
- William Vambenepe
In a new post, Oracle's William Vambenepe, a REST proponent, says there are some situations where the REST protocol may not always be a good fit. Here's a few of his observations on some "round holes":
- Long-lived operations. "You can’t just hang on for a synchronous response."
- Query: "I’ve seen proposals that create a 'query' resource and build it up incrementally by POSTing constraints to it. Very RESTful. Very impractical too."
- Events: "You quickly end up worrying a lot more about firewalls and the cost of keeping HTTP connections open than about RESTful purity."
- The afterlife: "How do you retrieve data about a resource once it’s gone? Which is what a DELETE does to it."
There's been an ongoing debate for years between proponents within the WS-*/SOAP and REST worlds. The bottom line is that each has a role to play as systems and infrastructures are stood up and built out in a service-oriented way.