> My main qualm about REST is the number of inputs for doing something: Path variables, query variables, POST input, headers and for shits and giggles the Http

> My main qualm about REST is the number of inputs for doing something: Path variables, query variables, POST input, headers and for shits and giggles the Http METHOD. As a sibling comment has already extensively described why this is the way it is, I want to add one more thing: REST is a set of principles leveraging what already exists in HTTP. And HTTP gives you a lot. Here's an extensive HTTP decision diagram with links to explanations on basically everything: https://github.com/for-GET/http-decision-diagram/tree/master/doc https://github.com/for-GET/http-decision-diagram/tree/master... Caching? HTTP got you covered. Editing conflicts? HTTP got you covered. A decision path for auth? HTTP got you covered. No-op requests? HTTP got you covered. Meanwhile GraphQL libs are busy reimplementing half of HTTP spec inside a single POST request.