This is why I prefer Sinatra-style programming. You don't have to waste brain cells on unnecessary abstractions that don't correspond to anything real.
You just have functions (not "controllers", or "operations") that respond to a particular url/method combination. Those functions job is to interpret the request and respond accordingly.
This style adds no new abstractions or opinions that aren't already in http. It formalizes what http already gives you, with some utility methods for the common things needed (content negotiation, etc).
This works for small services and apps, but I think it'd be quite a maddening exercise to try and keep a large codebase consistent and organized with that method.
In my opinion it also works for a large codebase. You just have to define your (REST) resources carefully, but they scale very well. The smaller details (on class/object level) are in your lib directory and have no direct relation with your Sinatra app. In fact your Sinatra app could also have been a command line app or something else.
It seems like with Sinatra if you do it right, you'd be doing MVC* anyway. Your route handler functions are the controllers, and your models are basically domain objects that handle business logic. Of course, if you do it wrong, you end up with request handler functions that are full of business logic, which is what a lot of MVC apps end up looking like anyway.
* Or at least, what web developers refer to as MVC.
Route functions aren't like controllers. Controller is an abstraction that has nothing to do with http. It doesn't correspond to http.
When MVC was shoehorned into http the controller was meant to control the resource, which is how people know of it. But it also controls the collection of resources.
The route function is much simpler than a controller, it only handles one particular method of a resource.
I don't really understand your point. In MVC, we use functions on the controller to handle the incoming request and the response. There is usually a router that routes an incoming request to the corresponding controller and function.
How is this different than what a route function does?
Similar thing with the web frameworks I use. I don't need MVC, but in reality I end up using something similar anyway. I render a template (essentially a view, Jinja2's pretty powerful), request functions are essentially controllers, and I have a set of functions and classes for manipulating data and performing operations that essentially form the models.
I think that's what is really important; understanding what concerns need to be separated instead of blindly creating models, views and controllers because that's how it is supposed to be done.
Yep. This design is partly because of lessons learned from experience: PHP development showed me that mixing things together and code duplication is a bad idea.
You just have functions (not "controllers", or "operations") that respond to a particular url/method combination. Those functions job is to interpret the request and respond accordingly.
This style adds no new abstractions or opinions that aren't already in http. It formalizes what http already gives you, with some utility methods for the common things needed (content negotiation, etc).