3 ms·
There is an advantage in separating "protocol" from "binding" (in this case, "HTTP binding"). While REST is typically explained as an HTTP-only protocol, this i
by lsh123 12y ago
There is an advantage in separating "protocol" from "binding" (in this case, "HTTP binding"). While REST is typically explained as an HTTP-only protocol, this is not the only possible "binding". I've successfully designed and implemented REST-style APIs using non-HTTP based RPC methods in the past. The main benefits in REST are not coupled with using HTTP GET/POST/PUT/DELETE but with the clearly defined model of resources, operations, client/server and limitations (e.g. statelessness) to make it a simple (but powerful) model.
- surajgupta 12y agoI agree with everything you've said. I intentionally did not separate "protocol" from "binding" in this deck. I wanted to take more of a pragmatic approach and less of an academic approach. In practice, REST is most often implemented on HTTP. Because devs can relate to HTTP, I coupled protocol and binding to keep things simple.