<story><title>What RESTful actually means</title><url>https://codewords.recurse.com/issues/five/what-restful-actually-means</url></story><parent_chain><item><author>pixie_</author><text>REST is the definition of a buzzword. Vague. Useless. Everyone talks about it, but no one ever &amp;#x27;understands&amp;#x27; it.  You make your API REST not because you think it&amp;#x27;s good, but because everyone else does it. It&amp;#x27;s instant karma. Like XML was 10 years ago. Who cares if you have to make a lot of ugly confusing endpoints - at least you can call your API RESTful.&lt;p&gt;I like how Dropbox bucked the trend and went with a simple POST based API. JSON parameters in. JSON response out. No complicated urls, strange headers, verbs, hateoas, etc..&lt;p&gt;&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;www.dropbox.com&amp;#x2F;developers&amp;#x2F;documentation&amp;#x2F;http&amp;#x2F;documentation&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;www.dropbox.com&amp;#x2F;developers&amp;#x2F;documentation&amp;#x2F;http&amp;#x2F;docume...&lt;/a&gt;</text></item></parent_chain><comment><author>bobfromhuddle</author><text>It&amp;#x27;s really not, I&amp;#x27;m sorry.&lt;p&gt;State is carried by the client, the client traverses links to find out what it can do, the responses are described by a published content type, and the content type defines the semantics of the protocol.&lt;p&gt;It&amp;#x27;s not hard, but people like to pretend that it is. Nothing says you can&amp;#x27;t stick to GET and POST, nothing requires weird headers.&lt;p&gt;&amp;quot;ReST in Practice&amp;quot; is a great introduction for engineers.</text></comment>
<story><title>What RESTful actually means</title><url>https://codewords.recurse.com/issues/five/what-restful-actually-means</url></story><parent_chain><item><author>pixie_</author><text>REST is the definition of a buzzword. Vague. Useless. Everyone talks about it, but no one ever &amp;#x27;understands&amp;#x27; it.  You make your API REST not because you think it&amp;#x27;s good, but because everyone else does it. It&amp;#x27;s instant karma. Like XML was 10 years ago. Who cares if you have to make a lot of ugly confusing endpoints - at least you can call your API RESTful.&lt;p&gt;I like how Dropbox bucked the trend and went with a simple POST based API. JSON parameters in. JSON response out. No complicated urls, strange headers, verbs, hateoas, etc..&lt;p&gt;&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;www.dropbox.com&amp;#x2F;developers&amp;#x2F;documentation&amp;#x2F;http&amp;#x2F;documentation&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;www.dropbox.com&amp;#x2F;developers&amp;#x2F;documentation&amp;#x2F;http&amp;#x2F;docume...&lt;/a&gt;</text></item></parent_chain><comment><author>jalfresi</author><text>REST is one of those things were if you don&amp;#x27;t implement all of it, you won&amp;#x27;t really reap the benefits of all those architectural constraints combined. In your Dropbox example, any client will be bound to the Dropbox API. Consequently, Dropbox are now bound to each and everyone of those clients; they cannot make changes on the server side without breaking every client. This is what REST aims to provide - a safe way for the server to change as needed without breaking clients.&lt;p&gt;Imagine if Dropbox registered a set of mime-types for each of the different resource representations. Those mime-type RFCs would describe how clients interpret the representations whilst simutainiously giving Dropbox the ability to change the server as they need without fear of breaking clients.&lt;p&gt;This would be because clients would be foxing on how to process the media-types, not the API. The various interactions a client can make with a representation (regardless of the URL it came from) would be bound to the media-type e.g. rel-types for edit, upload, create etc which the RFC would describe the appropriate HTTP interactions e.g. POST a media-type of x to the url at rel-type &amp;quot;edit&amp;quot;.&lt;p&gt;However, I think the real reason that REST hasn&amp;#x27;t been adopted fully is that service providers like Dropbox have found that there advantages to binding client developers to their hardcoded APIs; the last thing Dropbox wants (and what REST would provide) is a standardised set of media-types and RFCs describing the interactions for a standardised way of interacting with an external cloud-based storage provider.&lt;p&gt;It&amp;#x27;s just another form of lock-in, and reminded the cynic in me of the bad old days of MS Office document lock-in.</text></comment>