Staying RESTful and triggering actions without saving a record

[email protected] wrote:

In any case, the arguments are whatever is defined in that particular
route. Run rake routes or look at your routes file to see what that
would be.

That doesn’t make any sense.

Whether it makes sense or not, it is the case. :slight_smile: �The arguments are the
:parameters in the route.

But I’ve never explicitly defined any parameters - and the notion of
the arguments simply being a params-like hash had never occurred to
me. I never saw it done.

I’ve definitely seen examples, but I couldn’t find them when I went
looking.

My output of rake routes does not show a
function name for put requests.

No, but if you’re using map.resources, the paths for PUT requests are
the same as for named GET requests.

also a point that was not being connected in my head.

Using a link to a PUT request, though, is extremely smelly. �Links
should practically always be GET.

not that i would do something so “ugly” as set a links appearance to
button - but does that make it any more acceptable?

No. It has nothing to do with appearance. PUT is for updating an
existing resource (generally through a form).

I’ve read plenty
of religious war associated with this concept and believe that it’s
best evaluated on a need by need basis.

I think that the need for a PUT link does not exist, period. If your
app is telling you that it wants a link, then it’s telling you that it
wants a GET, perhaps with a custom verb or extra parameter.

Just never do PUT links (if you even can – I’m not sure :method works
on links; I hope it does not).

In the workflow of my
application a link that is styled a certain way most certainly conveys
to the user that it “does something important”. With xss protection in
rails and good testing it should be perfectly safe.

There’s also the stuff about named routes in ActionController::Routing.

Again, it depends on how your routes are defined.

That sentence should be added to the docs somewhere.

It’s pretty clear if you read the class doc.

Best,

Marnen Laibow-Koser
http://www.marnen.org
[email protected]

No. It has nothing to do with appearance. PUT is for updating an
existing resource (generally through a form).

and i am updating a resource… i’m not using #update_attributes, but
in my controller I am saving.

I think that the need for a PUT link does not exist, period. If your
app is telling you that it wants a link, then it’s telling you that it
wants a GET, perhaps with a custom verb or extra parameter.

Destroy links are still the default in rails - destroy and put are
similar in that they both change data.

Just never do PUT links (if you even can – I’m not sure :method works
on links; I hope it does not).

It does – and from what I’ve read - the implementation is sound. I
have a confirmation dialog on the link further narrowing the scope of
things that could go wrong.

It’s pretty clear if you read the class doc.

That’s a matter of opinion.

Thanks for your help.

[email protected] wrote:

No. It has nothing to do with appearance. PUT is for updating an
existing resource (generally through a form).

and i am updating a resource… i’m not using #update_attributes, but
in my controller I am saving.

That’s an irrelevant implementation detail. update_attributes is just a
shorthand for save anyway.

I think that the need for a PUT link does not exist, period. If your
app is telling you that it wants a link, then it’s telling you that it
wants a GET, perhaps with a custom verb or extra parameter.

Destroy links are still the default in rails - destroy and put are
similar in that they both change data.

Nothing view-related is the default in Rails. Or do you mean that Rails
puts them in the scaffolds it generates?

In any case, DELETE and PUT have some important differences, the most
fundamental being the inclusion of additional data in the PUT.

A state change may be implemented as a field update, but it is not
conceptually the same thing as, say, changing a name. Therefore, PUT is
inappropriate, and you want a custom GET action instead.

Against this I’d set the fact that such a GET action wouldn’t be
idempotent no matter how you look at it. Hmmm…

Just never do PUT links (if you even can – I’m not sure :method works
on links; I hope it does not).

It does – and from what I’ve read - the implementation is sound. I
have a confirmation dialog on the link further narrowing the scope of
things that could go wrong.

The confirmation is strictly a UI refinement. It won’t work if
JavaScript is turned off. It might prevent a user from doing something
in error. Might.

It’s pretty clear if you read the class doc.

That’s a matter of opinion.

Thanks for your help.

Best,

Marnen Laibow-Koser
http://www.marnen.org
[email protected]