Questions about callbacks

[rfestag]

This isn't so much an issue as me trying to understand why some callbacks work the way they do.

1. Why is create_path called so early? I see justifications like "Rails made us lazy" and "PUT should replace, not update", but still don't grasp an architectural/security related reason. I've also heard people say that exposing database ids in the URL is bad security practice, but fail to see the logic in that. If a resource should be protected, that should be done through authentication/authorization, not obscurity in how you look the resource up. If we have something (a database) that can automatically provide a unique ID (so I don't have to roll my own, and guarantees uniqueness even when I have multiple independent servers), why shouldn't I use that? Additionally, what if I want the id to be a slug generated from the request data (say, taking the title of a posted JSON object, which I don't have until from_json is called). This isn't a huge deal for me (I'm using Mongoid, so I can just generate an object id manually just as easily and still have the same uniqueness guarantees, although that doesn't solve the slug issue). It just seems odd and I'd be interested in understanding the reason.

2. Why do I have to manually set headers and response codes in process_post? Is there a reason we can't have it also go through the to_* callbacks defined by the content_types_provided mappings? I understand making that change now would probably be breaking, so we probably don't want to change that behavior, just trying to understand what makes it distinct?

3. Similar to this, what about error messages? If I want to return useful error information, I have to find out what the negotiated content type is, and format my body appropriately (and set the header), presumably in handle_exception

As some background, I'm trying to write sort of self-generating resources as an exercise to understand Webmachine better. It basically involves dynamically generating Webmachine::Resource Objects based on a provided model (and optional controller). The default controller provides standard implementations for "Railsy" controller operations (like show, list, create, update, and delete). If you define a custom controller, I want to be able to automatically add extra actions to the resources (say, /orders/:id/cancel if you define a cancel method). That is mostly where question 2 comes into play...in order to support that, I need to manually check the negotiated content type and call the appropriate callback.

[rfestag]

Just wanted to touch base on this, since I'm spending a bit more time playing with it. I'm particularly interested in 2) above.

I'm mostly just trying to get a handle on why posts are explicitly excluded from :o18 processing, and instead go to :o18b. It would seem to me that the developer could check in their content_types_provided callback what the appropriate response is if needed, and return the appropriate body (although, in many cases, I wouldn't be surprised if resources that use process_post are often in their own resources). I'm currently basically copying the existing logic for determining the correct response type/callback (and I would assume also encoding) so that it is available to use in my resource directly.