[LeonidBugaev]

Agree. The whole point of rules is that you allowed to break them from time to time.

During development with Rails I struggled a lot, because it was forcing CRUD ideology in places where the custom route could work (and adding it was so painful).

Standardization is fine, but usually it does not solve development issue, it solves management issue, which is common for big orgs not small ones. Especially when it gets on hype or forced by the top management, like it happened numerous times, with latest examples of React, GraphQL or Microservices.

[wukerplank]

Hm, I never found adding custom routes to Rails painful - could you elaborate? Anyway, for smaller use cases I found Sinatra + ActiveRecord a great match.

[rajangdavis]

Sinatra is awesome! Had a project recently where Active Record and Postgres with Sinatra made sense and it was completely painless.

Rails _might_ have helped, but I have come to enjoy Sinatra's flexibility. Been debating about making something in between, but working on other things.

[LeonidBugaev]

I'll be frank, the latest Rails version I used was Rails 3, and it was like 6 years ago, so I can't really remember details, except that I had to spread logic to like 3 files to make it work. Maybe things changed.

[yxhuvud]

No, you didn't have to spread out the logic like that in Rails3. You could do something like

    class AsController < ApplicationController
      def index
      end

      class BsController < ApplicationController
        def create
        end
      end
    end

with routes like

     resources :as do
       resources :bs, controller: "as/bs", only: :create
     end

[ryanbrunner]

Even that is resourceful routing, just with nested resources. Doing a flat out custom route is even easier:

    class AsController < ApplicationController
      def custom
      end
    end

routes:

    resources :as do
      member { get :custom }
    end

[yxhuvud]

Yes, of course.

The whole point of my example was that it is possible to do resourceful routing in a single file without having to resort to using custom routes. I try to avoid custom routes whenever possible - in my experience they lead to pain in the long run, more often than not.

[jively]

True, in general any framework that claims to help build REST APIs can put you in a situation where it forces assumptions on you.

Then the interpretation becomes the pattern, and it becomes a self-perpetuating fallacy.

[mschaef]

> During development with Rails I struggled a lot, because it was forcing CRUD ideology ...

This reminds me a bit of my first experiences with Common Lisp to write anything resembling serious code. (A Java compiler for my compilers class in school.)

My education to that point had almost entirely been driven from a purely list based and functional view of the language. Instructors would default to lists at the expense of other data structures and strongly encourage 'non-destructive' operations at the expense of mutation. (Even the term 'destructive' carries with it an obvious negative and somewhat dangerous connotation.)

Flash forward a couple semesters, and I'm trying to take this approach beyond writing simple unifiers and minimax search and apply it to a compiler with multiple layers of code that's being built up in phases over months. A month or so in, my resolve cracked, I started exploring some of the other options provided by the language (hash tables, vectors, mutation, etc.) and made a bunch more progress (and got something working by the end of the class).

My point in saying this isn't really to advocate for mutation, etc., but rather to agree with your point that sometimes it's worth breaking out of self-imposed constraints so that you can face the external constraints that are probably more important. (ie: my business client probably doesn't give a damn if my RESTful interface is RMM level 2 or three as long as it lets her effectively run her business.)

(One thing I'll add about the Lisp experience above is that it was more than half a lifetime ago... I'd probably be more nuanced with my use of mutation, etc. now than I was then. But then, I was much less experienced and a refugee from Pascal, etc. One of my constraints was my instructors' encouragements to avoid mutation... but another of my constraints was my own lack of techniques for working that way.)

[sureaboutthis]

Standardization is in place for interoperability issues, not management.

Rules are NOT made to be broken, as you claim, and I see more people getting themselves into trouble for thinking that.

This is computer science, not a game.

[coldtea]

No, it's absolutely not "computer science".

In fact the rules you talk of are totally ad hoc and/or cargo cult. At best, they're self-reported empirical (pre-scientific) findings.

There's no systematic research that they're better than some alternative set of rules etc. People just adopt this or that framework or methodology (like REST) because some famous programmer wrote it or suggested it, some company promoted it, it picked up steam of GitHub and blogs, and so on.

That's not only not "computer science", it's not even "software engineering".