restful camping

[camping]

restful camping

[zuk]

I'm the guy who originally wrote Reststop, and to be honest I don't particularly like writing out the resource name twice when defining a restful controller or having to explicitly write out obvious XML views. It's been a while since I've even looked at this code (~2 years) but if I recall correctly a lot of these design decisions were made because of certain constraints in the way Camping does things. I can't remember my reasons exactly, but I do remember being pretty frustrated the entire way through. If it were up to me, Reststop's functionality would be incorporated into Camping's core. This could make the syntax for doing things restfully a lot more flexible.

I do understand though why Magnus is reluctant to do this. We had a conversation about this a while back. What he likes about Camping is it's minimalism, and incorporating major changes like this into the core could really screw with what Camping is all about (for him, anyway).

But doing what you're asking, in my experience, would be too awkward without making changes to Camping itself. I don't think you're going to see this functionality without some big refactoring.

[judofyr]

I think zuk expresses my opinion better than I can :-)

I do understand though why Magnus is reluctant to do this. We had a conversation about this a while back. What he likes about Camping is it's minimalism, and incorporating major changes like this into the core could really screw with what Camping is all about (for him, anyway).

But of course: If that's what the Camping community want, that's what the Camping community will get. Both of you are owners of the Camping organization on GitHub and are free to commit whatever you like (in the same way as I do), but I would of course strongly recommend asking around before committing anything as big as this.

Well, as long as Camping stays at 4k, I think such a RESTful-feature would do no harm. How we're going to get it in under 1k (and still be useful) is beyond my imagination…

[busbey]

the size constraint is easy. we just use autoload. i don't care for the cheating, but we do it crazy much as it is. I mean all of our ActiveRecord stuff is autoloaded.

[judofyr]

The thing about the database and template layer is that it's very much replaceable parts. It's only there for integrating with other libraries. But anyway: If it can be implemented with autoload, it can also be implemented in a separate project.

[techarch]

From my perspective I feel that the definition of REST routes belong to the controller as opposed to the model. The model should remain about the data and persistence I think.
That said we could improve the syntax: what about giving the controller a simple base class (REST)? This would eliminate the repetition on the controller declaration.
For the views we could use some conventions to auto-render using the format corresponding to the declared view module (e.g. XML,JSON, etc).
What do you think?

[karloscarweber]

I know this thread is 12 years old but I don't like the idea of making Models in charge of endpoints. Having explicit Views that render Json is a good abstraction to have.

I agree with what @techarch has said.

Often times REST APIs also have authentication requirements or visibility restrictions on the data. That's one reason we have the controllers in the first place, to gate actions with logic. Broad gates or transformations happen via middleware.

But having an extension to Views to specify the type of Data being Rendered is a good idea. This probably doesn't need to be an explicit extension, but something that can be patched in. We could outline the method and it's use cases in a guide and then recommend that guide when someone wants to have REST endpoints.