# RESTful thinking considered harmful - followup

DevFeed: [RESTful thinking considered harmful - followup](<https://devfeed.tech/articles/restful-thinking-considered-harmful-followup-1272.md>)

Original publisher: [Read original article](<https://shopify.engineering/17488868-restful-thinking-considered-harmful-followup>)

Author: Willem van Bergen

Published: 2012-03-31T22:45:00Z

Content type: opinion

Language: en

Sources: [Shopify Engineering](<https://devfeed.tech/sources/shopify-engineering.md>), [Shopify Engineering - Shopify Engineering](<https://devfeed.tech/sources/shopify-engineering-shopify-engineering.md>)

Topics: [Rails](<https://devfeed.tech/topics/rails.md>), [CRUD](<https://devfeed.tech/topics/crud.md>), [API](<https://devfeed.tech/topics/api.md>), [Architecture & Design](<https://devfeed.tech/topics/architecture-design.md>), [Security](<https://devfeed.tech/topics/security.md>)

Tags: [api](<https://devfeed.tech/tags/api.md>), [bugs](<https://devfeed.tech/tags/bugs.md>), [design](<https://devfeed.tech/tags/design.md>), [documentation](<https://devfeed.tech/tags/documentation.md>), [rails](<https://devfeed.tech/tags/rails.md>), [rest](<https://devfeed.tech/tags/rest.md>), [security](<https://devfeed.tech/tags/security.md>), [tutorials](<https://devfeed.tech/tags/tutorials.md>)

## AI overview

This follow-up clarifies that the author is not arguing against REST itself, but against the way Rails teaching materials encourage developers to equate REST with CRUD. The article argues that modeling actions such as publishing a blog post as resources can be unintuitive, leading developers to misuse update actions and potentially lose data. It prioritizes building a correctly functioning application over strict REST adherence and proposes state-machine support, generators, and improved educational materials for Rails.

## Source excerpt

My previous post RESTful thinking considered harmful caused quite a bit of discussion yesterday. Unfortunately, many people seem to have missed the point I was trying to make. This is likely my own fault for focusing too much on the implementation, instead of the thinking process of developers that I was actually trying to discuss. For this reason, I would like to clarify some points. My post was not intended as an arguments against REST.