デフォルトを使用するRailsアプリケーションがあり、現在すべてのルートをキャッチしています。これは、通常のHTMLリクエストで正常に機能します。
match ':controller(/:action(/:id))(.:format)'
CRUD機能をモバイルクライアントに公開したいと思います。では、再利用可能なリクエスト（JSON）をサポートするためにすでに必要なものをどのように拡張すればよいですか？デフォルトルートの前にroute.rbにリソースルートを追加する必要がありますか？または、リソースルートを優先してデフォルトルートの使用を停止する必要がありますか？別のオプションは、matchを使用してRESTfulルートを明示的に指定することである可能性があると思います。しかし、これは間違っているようです。
アドバイスありがとうございます！
他に何を決定するかに関係なく、デフォルトのキャッチオール ルートを捨てることを検討する必要があります。ルートを明示的に記述すると、ビューのルートに名前が付けられたり、ルートで実際に何が起こっているかに関するドキュメントとして機能したりするなど、多くの利点が得られます。
さて、技術的には、形式に関係なく、ほとんどのリクエストを処理するために、参照されたルートをまったく調整する必要はありません (/like/this/route/is が深すぎない限り)。ほとんどの場合、リソース ルートは適切であり、出発点としては適切ですが、実際には、あなたが言及したすべてのルートを明示的に記述することを好むようになりました。少し冗長ですが、いくつかの利点があります。最初の利点はパフォーマンスです。ルートが少ないほどルーティングが速くなり、ルートを明示的に示すことで、未使用のルートを削除する機会を強調できます。この方法のもう 1 つの利点は、追加の構成可能性です。2 つの REST-ful ルートを同じコントローラー アクションに送信できる場合があります。これは、DRY の少ないコントローラー/ビューにつながるロジックの重複が原因です。ついに、キャッチオール ルートを削除するのと同じように、ルートのライブ ドキュメントとして機能します。コンソールを実行するためにドロップする必要はもうありません。rake routesコマンドを実行して、ルーティングで何が起こっているかを確認します。私は次の男と同じくらいレールマジックが好きですが、これは私のレールアプリで追加の冗長性が歓迎される数少ない領域の1つであると感じています.