QA@IT
«質問へ戻る

微調整

463
本文
 
 そのため、単純な開発効率や、ルーティングの分かり易さ、共同開発者内での認識統一の図りやすさ、などの点では「match ':controller(/:action(/:id))(.:format)'」この一行の設定だけ書いておけば、全てのルーティングを一つのルールで理解できるため、分かり易く、事故も起き難いのではないか、というような気もしています。(ルーティングの設定に掛ける時間も短縮でき、その分、本質的なアプリケーションの開発に割ける時間に充当できるとも考えられます。)
 
-非推奨とする理由としては、全てのルーティングにGETアクセス出来てしまう、RESTful設計に準拠すべき、Railsの流れに従うべき、などの理由があるのかと思いますが、上記に挙げた利点なども鑑み、それでもコスト対効果で効果の方が上回る、もしくは使うべきでは無い絶対的理由などは何かあるのでしょうか?
+非推奨とする理由としては、全てのルーティングにGETアクセス出来てしまう、RESTful設計に準拠すべき、Railsの流れに従うべき、などの理由があるのかと思いますが、上記に挙げた利点なども鑑み、それでもコスト対効果で効果の方が上回る、もしくは使うべきでは無い絶対的理由などはあるのでしょうか?
 
 

routes.rbの「match ':controller(/:action(/:id))(.:format)'」はなぜ使わない方が良いのでしょうか?

Railsのroutes.rbの「match ':controller(/:action(/:id))(.:format)'」というルーティングの設定方法は非推奨とされているかと思います。

config/routes.rb

  # This is a legacy wild controller route that's not recommended for RESTful applications.
  # Note: This route will make all actions in every controller accessible via GET requests.
  # match ':controller(/:action(/:id))(.:format)'

しかし、少し大きめのWebアプリケーションや、複雑なページ遷移を必要とするWebアプリケーションなどでは、routes.rbの記述が複雑になってしまったり、優先順位の関係で、予期せぬ動作不良を起こしてしまうような場合もあるのではないかと思っています。

そのため、単純な開発効率や、ルーティングの分かり易さ、共同開発者内での認識統一の図りやすさ、などの点では「match ':controller(/:action(/:id))(.:format)'」この一行の設定だけ書いておけば、全てのルーティングを一つのルールで理解できるため、分かり易く、事故も起き難いのではないか、というような気もしています。(ルーティングの設定に掛ける時間も短縮でき、その分、本質的なアプリケーションの開発に割ける時間に充当できるとも考えられます。)

非推奨とする理由としては、全てのルーティングにGETアクセス出来てしまう、RESTful設計に準拠すべき、Railsの流れに従うべき、などの理由があるのかと思いますが、上記に挙げた利点なども鑑み、それでもコスト対効果で効果の方が上回る、もしくは使うべきでは無い絶対的理由などはあるのでしょうか?

Railsのroutes.rbの「match ':controller(/:action(/:id))(.:format)'」というルーティングの設定方法は非推奨とされているかと思います。

config/routes.rb

```ruby
  # This is a legacy wild controller route that's not recommended for RESTful applications.
  # Note: This route will make all actions in every controller accessible via GET requests.
  # match ':controller(/:action(/:id))(.:format)'
```

しかし、少し大きめのWebアプリケーションや、複雑なページ遷移を必要とするWebアプリケーションなどでは、routes.rbの記述が複雑になってしまったり、優先順位の関係で、予期せぬ動作不良を起こしてしまうような場合もあるのではないかと思っています。

そのため、単純な開発効率や、ルーティングの分かり易さ、共同開発者内での認識統一の図りやすさ、などの点では「match ':controller(/:action(/:id))(.:format)'」この一行の設定だけ書いておけば、全てのルーティングを一つのルールで理解できるため、分かり易く、事故も起き難いのではないか、というような気もしています。(ルーティングの設定に掛ける時間も短縮でき、その分、本質的なアプリケーションの開発に割ける時間に充当できるとも考えられます。)

非推奨とする理由としては、全てのルーティングにGETアクセス出来てしまう、RESTful設計に準拠すべき、Railsの流れに従うべき、などの理由があるのかと思いますが、上記に挙げた利点なども鑑み、それでもコスト対効果で効果の方が上回る、もしくは使うべきでは無い絶対的理由などはあるのでしょうか?

質問を投稿

routes.rbの「match ':controller(/:action(/:id))(.:format)'」はなぜ使わない方が良いのでしょうか?

Railsのroutes.rbの「match ':controller(/:action(/:id))(.:format)'」というルーティングの設定方法は非推奨とされているかと思います。

config/routes.rb

  # This is a legacy wild controller route that's not recommended for RESTful applications.
  # Note: This route will make all actions in every controller accessible via GET requests.
  # match ':controller(/:action(/:id))(.:format)'

しかし、少し大きめのWebアプリケーションや、複雑なページ遷移を必要とするWebアプリケーションなどでは、routes.rbの記述が複雑になってしまったり、優先順位の関係で、予期せぬ動作不良を起こしてしまうような場合もあるのではないかと思っています。

そのため、単純な開発効率や、ルーティングの分かり易さ、共同開発者内での認識統一の図りやすさ、などの点では「match ':controller(/:action(/:id))(.:format)'」この一行の設定だけ書いておけば、全てのルーティングを一つのルールで理解できるため、分かり易く、事故も起き難いのではないか、というような気もしています。(ルーティングの設定に掛ける時間も短縮でき、その分、本質的なアプリケーションの開発に割ける時間に充当できるとも考えられます。)

非推奨とする理由としては、全てのルーティングにGETアクセス出来てしまう、RESTful設計に準拠すべき、Railsの流れに従うべき、などの理由があるのかと思いますが、上記に挙げた利点なども鑑み、それでもコスト対効果で効果の方が上回る、もしくは使うべきでは無い絶対的理由などは何かあるのでしょうか?

Railsのroutes.rbの「match ':controller(/:action(/:id))(.:format)'」というルーティングの設定方法は非推奨とされているかと思います。

config/routes.rb

```ruby
  # This is a legacy wild controller route that's not recommended for RESTful applications.
  # Note: This route will make all actions in every controller accessible via GET requests.
  # match ':controller(/:action(/:id))(.:format)'
```

しかし、少し大きめのWebアプリケーションや、複雑なページ遷移を必要とするWebアプリケーションなどでは、routes.rbの記述が複雑になってしまったり、優先順位の関係で、予期せぬ動作不良を起こしてしまうような場合もあるのではないかと思っています。

そのため、単純な開発効率や、ルーティングの分かり易さ、共同開発者内での認識統一の図りやすさ、などの点では「match ':controller(/:action(/:id))(.:format)'」この一行の設定だけ書いておけば、全てのルーティングを一つのルールで理解できるため、分かり易く、事故も起き難いのではないか、というような気もしています。(ルーティングの設定に掛ける時間も短縮でき、その分、本質的なアプリケーションの開発に割ける時間に充当できるとも考えられます。)

非推奨とする理由としては、全てのルーティングにGETアクセス出来てしまう、RESTful設計に準拠すべき、Railsの流れに従うべき、などの理由があるのかと思いますが、上記に挙げた利点なども鑑み、それでもコスト対効果で効果の方が上回る、もしくは使うべきでは無い絶対的理由などは何かあるのでしょうか?