I'll take REST over SOAP any day of the week. Every time I've dealt with SOAP it's been magnitudes of times more confusing and frustrating than any REST endpoint I've used.
That said this article is SPOT ON with the failings of REST. The bit on HTTP error codes hit me hard. At my last company we used unused HTTP codes to represent various server errors (we kept them in the correct ranges for client/server errors). The only problem is at some point someone used 408 ("408 Request Timeout") to indicate the server timed out (we should have used "504 Gateway Timeout"). I'm sure someone typed something like "HttpStatus.Timeout" and the IDE helpfully provided "HttpStatus.REQUEST_TIMEOUT" and they said "well it's a request and it's timing out so perfect". Unfortunately modern browsers see a 408 and think THEY did something wrong (That they didn't send the request fast enough) and so it RETRIES THE REQUEST!
> HTTP existed long before “RESTful webservices”, and the web ecosystem is filled with assumptions about the meaning of its error codes. Using them to transport application errors is like using milk bottles to dispose of toxic waste: inevitably, one day, there will be trouble.
So while we would be debugging a request the browser would get a 408 from our server (because we had paused execution for longer than our http adaptor's timeout for talking to backend, the browser would resubmit the same request, and once we had resumed debugging we would get a second message dropped into the system. We wrote this off for MONTHS as some debugging-related oddity. I know I personally took 5-10 minutes on multiple occasions to track it down but the Chrome network monitor DOES NOT show the retry which makes it even more confusing.
Finally we were forced to find the issue and fix it... when it took down production. We had an endpoint that started to hang a huge part of the system (it was a bug where it couldn't handle the amount of data in prod) and when it timed out the browser would just retry the request so every open web browser pointed at our site because a DDOS client.
That said this article is SPOT ON with the failings of REST. The bit on HTTP error codes hit me hard. At my last company we used unused HTTP codes to represent various server errors (we kept them in the correct ranges for client/server errors). The only problem is at some point someone used 408 ("408 Request Timeout") to indicate the server timed out (we should have used "504 Gateway Timeout"). I'm sure someone typed something like "HttpStatus.Timeout" and the IDE helpfully provided "HttpStatus.REQUEST_TIMEOUT" and they said "well it's a request and it's timing out so perfect". Unfortunately modern browsers see a 408 and think THEY did something wrong (That they didn't send the request fast enough) and so it RETRIES THE REQUEST!
> HTTP existed long before “RESTful webservices”, and the web ecosystem is filled with assumptions about the meaning of its error codes. Using them to transport application errors is like using milk bottles to dispose of toxic waste: inevitably, one day, there will be trouble.
So while we would be debugging a request the browser would get a 408 from our server (because we had paused execution for longer than our http adaptor's timeout for talking to backend, the browser would resubmit the same request, and once we had resumed debugging we would get a second message dropped into the system. We wrote this off for MONTHS as some debugging-related oddity. I know I personally took 5-10 minutes on multiple occasions to track it down but the Chrome network monitor DOES NOT show the retry which makes it even more confusing.
Finally we were forced to find the issue and fix it... when it took down production. We had an endpoint that started to hang a huge part of the system (it was a bug where it couldn't handle the amount of data in prod) and when it timed out the browser would just retry the request so every open web browser pointed at our site because a DDOS client.