| Subject: | Why does create_path happen before the accepted handler? |
The order of operations in step N11 of the FSM states doesn't make sense to me. If this is a
post_is_create operation, we immediately setup the create path. This, then, sets up the Location
header in the response. However, this happens even before we know what the status response
is and Location only makes sense for 201 (the assumed most likely), 300, 301, 302, 303, 305,
and 307 responses.
Furthermore, the most useful thing to do is to create the new item inside the accept handler,
e.g., from_json. It is very likely that a typical application (e.g., mine or fREW's drinkup) won't
even know the path to redirect to until *AFTER* the JSON is parsed and probably not until after
the JSON has been used to create a record and some auto-increment or UUID or whatever has
been created. All of this happens after we have already setup the Location header.
fREW's solution looks like the one I will have to do as well:
sub post_is_create { 1 }
sub create_path { "worthless" }
sub from_json {
my $obj = $_[0]->create_resource(
$_[0]->decode_json(
$_[0]->request->content
)
);
$_[0]->redirect_to_new_resource($obj);
}
The above was taken from
https://github.com/frioux/drinkup/blob/master/lib/DU/WebApp/Resource/Role/Set.pm
At least an explanation of this ordering would be nice to have in the documentation for
Web::Machine::Resource. Personally, I would like to see the order of operations swapped so that
Location is setup after we are sure we know what we've just created (if anything).
Cheers.