REST isn&#x27;t a protocol, it&#x27;s an argument for an approach to systems architecture that minimizes coupling between components while maximizing client reuse.<p>I&#x27;ve designed and operated several REST-inspired systems over the years, and let me warn you: it&#x27;s no walk in the park.  Engineers that want to &quot;get it done now&quot; must be convinced not to huck everything up to the server as a POST.  Founders have to see the business case for every new system.  Other departments may have to relearn tools for interoperating with the systems.  It&#x27;s a whole big deal. You can&#x27;t deploy a RESTful solution and avoid dealing with <i>people</i>.<p>For your effort, you&#x27;ll receive a system with well-factored bounded contexts whose self-descriptive interfaces interoperate with standardized tooling and monitoring systems. Projects can be factored into tasks along clear domains and often incrementally delivered into production.   Life-sucking productivity projects like the <i>secret admin website</i> can be pushed off indefinitely. Problems will be simple to isolate and reproduce. You&#x27;ll have the flexibility to rush out brand new client experiences on tight deadlines.<p>Notice how none of the problems or benefits really involve a particular technology tool or framework or language?<p>In my opinion, ignorance of the significant cultural factors required for a successful deployment of a RESTful system is <i>the</i> reason why articles continue to be published about how it&#x27;s vague or difficult or whatever.