Hi, I have an idle question. I come from Rails and noticed that Hanami similarly has a resources route method that will create a route for a destroy action, even though the HTTP action is DELETE. The getting started guide for Hanami even provides pseudo-code for a Delete action, although in my experience that’s erroneous and requires a Destroy action instead.
I’m mostly curious if this is some kind of standard web convention that I’ve just taken for granted all my life, or if it’s maybe a relic of an older iteration of this framework.
I’m not on the core team, nor can I speak to the reasoning behind how `resources` was implemented but the use of `destroy` instead of `delete` is a constant source of frustration for me. It’s also why I haven’t used the `resources` feature for any resource that needs a delete action because this mapping is so awkward.
Prior to the introduction of the `resources` feature, your routes would use `delete` (not `destroy`) as it’s a wonderful logical mapping and true to the HTTP specification. Being able to think in terms of HTTP verbs is something I relished coming to Hanami after using Rails for many years. Unfortunately, with the introduction of the `resources` feature, that was taken away.
If I had my druthers, I’d love to see a future version of Hanami where this was fixed so that you can think of your routes and corresponding actions as “deletes”. Then everything becomes a straightforward one-to-one mapping.
This is a good observation, thank you for raising it, @Buzzkill-McSquare!
When I first shepherded this resources DSL through, my thinking regarding the delete/destroy combo was “one less unfamiliar thing to Rails developers, probably a net positive.”
What’s far more valuable than my hunch at a moment in time, however, is real feedback from our users! Given your question, and @bkuhlmann’s input too, I’m inclined to agree with you both. “Destroy” as a name might make sense when that’s the key ActiveRecord method you call from that endpoint, but we don’t use ActiveRecord here, and parity with the HTTP verb is a much stronger position.
The resources DSL has only been in place for 6 months. I think we could probably withstand a change to its generated routes. I’ll chat with the team and see if we can find a way forward here. If either of you have suggestions about this, I’d be happy to hear it too
This is my first real foray into the “Ruby but not Rails” world so I’m still learning what’s core vs. what’s added by the Rails framework, but I wonder if you could support both where destroy becomes an alias of delete? That’d reduce onboarding friction for those developers whose muscle memory is to reach for destroy while keeping delete as the accurate path.
Then again, if the tool is still so young then maybe sticking to a strong opinion and enforcing delete is the way to go? Hopefully a breaking change like that won’t impact too many systems right now.
I like “destroy” because it lets the set of HTTP verbs and action names be completely distinct. If we name it “delete” then e.g. DELETE → Delete action, and there’s overlap. DELETE is also a SQL statement but there are plenty of cases where the ‘destroy’ action is doing something other than a SQL DELETE, e.g. logging out, soft-deletes, two-phase deletion, marking something as ‘canceled’.
The HTTP verb and SQL commands are out of our control, so having a distinct name to signal that we’re triggering a domain action that may not be a SQL DELETE is useful. “destroy” is clearly not an HTTP verb and also clearly not a SQL statement. Especially for people new to web apps, this can be a useful distinction.
In Rails they end up calling #destroy instead of #delete, to trigger callbacks. But this applies for us too, where the domain action may very well do something other than just a SQL DELETE.
Thank you @cllns, this is a convincing case. I’m convinced, anyway.
If you’ll allow me to re-present it: resource routing, as we offer it, presents a certain domain modelling for the actions. This is its main benefit as a convenience—follow the model and you reduce toil and achieve cleaner routes files. “Destroy” is the name chosen for that particular action within the domain model. “Update” is another, and it’s worth noting that we don’t try and call those actions “Patch”, even though that is the HTTP verb for their routes.
So given this is already a released feature, I think it’s best we leave this as it is. As a user of resource routes, you can learn the mappings once, and as you use them throughout your app, they’ll quickly become second nature.
These are good arguments all around! @cllns makes a good case and @timriley you’re right that there’s already precedent. This is the conversation that I needed to have when I started thinking too hard about it last night!
