リモートリソースの再起動に適したHTTPメソッド（GETまたはPUT）を（ある意味で）判断するのに苦労しています。
一方でhttp://tools.serviceprovider.net/canopies/d34db33fc4f3?reboot=trueは、新しく再起動されたキャノピーの表現を取得したい場合があるため、呼び出す方がセマンティックに思えます。
一方、再起動は「安全」ではないため（必ずしもべき等ではありませんが、キャノピーまたはモデムはデータベース内の単なる行ではありません）、キャノピーを再起動の状態にする方が意味的に見える場合があります。次に、サーバーに202を返して、再起動が開始されて処理中であることを示します。
私は先週、HTTP / 1.1、REST、HATEOAS、およびその他の関連する概念について読んでいたので、まだそれらをまとめています。よりベテランの開発者は、私の予感を確認または払拭してください。
あなたが言ったように、GETは「安全」であることが期待されているため、GETは適切ではないようです。つまり、取得以外のアクションはありません。
PUT はべき等であると予想されるため、PUT は適切ではないようです。つまり、複数の同じ操作は、単一の操作と同じ副作用を引き起こします。さらに、PUT は通常、リクエスト URI のコンテンツをリクエスト本文に置き換えるために使用されます。
ここでは POST が最も適切に見えます。なぜなら：
303 See Otherまた、再起動のリクエストを POST しているという点でも意味があるように見えます (フォームを送信するのと同じように、POST を介して行われます)。これはその後処理され、ステータスと共に返される再起動ログ/結果を含む新しい URI につながる可能性があります。コード。
興味深いことに、Tim Bray は、まさにこのトピック (仮想マシンを表すリソースにそれ自体を再起動するように指示するために使用する方法) に関するブログ投稿を書き、その中で彼は POST についても主張しました。その投稿の下部には、そのトピックに関するフォローアップへのリンクがあり、同意する Roy Fielding 自身からのものも含まれています。
残りは間違いなくHTTPではありません。しかし、HTTPには間違いなく4つ（または8つ）のメソッドしかないわけではありません。すべてのメソッドは技術的に有効であり（拡張メソッドとしても） 、「LOCK」、「REBOOT」、「DELETE」などの自己記述型のメソッドはRESTfulです。「MUSHROOM」のようなものですが、 HTTP拡張機能には、明確な意味や簡単に予想される動作がないため、RESTfulではありません。
フィールディングは次のように述べています。「RESTスタイルは、メソッドのセットを制限することが望ましい目標であることを示唆していません。[..]特に、RESTは、あいまいな操作のための新しいメソッドの作成を奨励します」そして「真のRESTベースのアーキテクチャでは、明確な（重複しない）普遍的なセマンティクスを持つ100の異なるメソッドがある方が効率的です。 。」</p>
出典：
http://xent.com/pipermail/fork/2001-August/003191.html
http://tech.groups.yahoo.com/group/rest-discuss/message/4732
これをすべて念頭に置いて、私は「自己記述的」であり、REBOOTメソッドを使用します。
はい、POST を使用して新しいコマンド REBOOT を効果的に作成できます。しかし、PUT を使用して再起動する完全にべき等な方法があります。
サーバーが最後に再起動された時刻を含む last_reboot フィールドを用意します。受信時刻が現在の時刻よりも新しい場合、現在の時刻でそのフィールドに PUT を実行すると、再起動が発生します。中間サーバーが PUT を再送信しても問題ありません。最初のコマンドと同じ値であるため、何もしません。last_reboot 時間を逆に設定しようとするとエラーになります。
クライアントとサーバーが適切に時刻同期されていることがわかっていない限り、再起動しているサーバーから現在の時刻を取得したい場合があります。