REST URIでアクション（動詞）を表す

お客様のドキュメントに対して実行する印刷操作があります。追加、更新、削除など、他の標準操作も実行する必要があります。だから、私は次のものを持っています：

• 新しい顧客を作成する場合：
  URI = / customer / {id}、タイプ= POST、Methodname = CreateCustomer（）
• 更新の場合：
  URI：/ customer / {id}、タイプ= PUT、メソッド= UpdateCstomer（）
• 顧客の削除：
  URI = / customer / {id}、タイプ= DELETE、メソッド名= DeleteCustomer（）
• ビューの場合：
  URI：/ customer / {id}、タイプ= GET、メソッド= GetCustomer（）

今、その顧客のためにドキュメントを印刷する必要がある場合、印刷機能が必要です。私のURIは次のようになります：/ customer / {id}、type = POST、method = PrintCustomer（）。しかし、CreateCustomerにはそのURIとPOSTタイプを使用しました。URIを/ customer / Print / {id}、タイプ= POST、メソッド= PrintCustomer（）のようにしたかったのです。

しかし、URIに「印刷」動詞を含めることはできません。これを行う最良の方法は何ですか？URIとして/ customer / document / {id}を考えましたが、同じ問題に遭遇します。「ドキュメント」に対してCRUD操作を実行します。それで、再び「印刷」に使用するものを使い果たしました。お知らせ下さい。

POST「作成」を意味するのではなく、「プロセス」を意味します。適切なリクエストを既存のリソースに投稿する（つまり/customers、新しい顧客を作成するために投稿する）ことで、新しいリソースを作成できます。しかしPOST、きちんとしたCRUDパラダイムに対応しない他のすべてのアクションを埋めるために使用することもできます。

印刷の場合、印刷自体をリソースとして考える必要があります。システムに「印刷ジョブ」を作成するように依頼しています。これはprints/、要求されたすべての印刷のコンテナとして機能するリソースを持つことができることを意味します。あなたが何かをあなたPOSTが作成したい印刷物に関するすべての情報を含むこのリソースにドキュメントとして印刷したいとき、それらへのリンクで印刷したいリソースを特定します。

JSONドキュメントとしては、次のようになります。

{
   contents: ["http://site/customers/12345"],
   paper-size: "A4",
   duplex: "true"
}

明らかに、あなたがやりたいことに関連するようにこれをカスタマイズする必要があります。重要なことは、URLを指定することにより、印刷する他のリソースを識別することです。

リクエストへの応答として、単純にa 200 OKまたはa 204 No-Contentを返して、それを火と忘れのプロセスとして扱うことができます。ただし、拡張する場合201 Createdは、新しく作成した印刷ジョブのURLを返し、指定できます（例：）/prints/12345。

その後、ユーザーはGETリソースでを実行して印刷ジョブのステータス（保留、進行中など）を確認したり、を発行してジョブのキャンセルを要求したりできDELETEます。

リソースの観点から問題を言い換えると、RESTfulなデザインは自然に生まれ、すぐには考えられなかった方法で拡張および強化する機会を与えるはずです。

前にこれをやった。ドキュメントを印刷するには、pdfバージョンのリソースを返すだけです。クライアントは、Acceptヘッダーapplication / pdfを持つリソースのGETリクエストを送信するだけです。

これにより、印刷ジョブなどの一時リソースの新しいURIの作成も回避されます。HTTPヘッダーの使用もRESTの一部であり、URIをクリーンに保ちます。

現在のURIのGETにパラメーターを追加するだけです

複数のアクションにURIを使用するのは非常に一般的です。

同じリソースで異なるアクションについて説明している場合は、それをパラメーターとして定義します。

/ customer / {id}？print = true

次に、GETメソッドを定義する場所で、印刷パラメーターの存在を検出し、異なる方法で処理します。

RESTは次の方法で定義されます。

• POST-レコード、アセット、またはリソースを作成します
• PUT-更新、レコード、資産、またはリソース
• DELETE-レコード、アセット、またはリソースを削除します

一方、GETは複数の方法で使用することを意図しています。これは、通常、リソースを取得できるさまざまなフォームが多数あるためです。GETリクエストがクエリ文字列として表されるのもそのためです。データベースリソースを使用していた場合、文字通りクエリを介してビューを取得することになりますが、RESTはさまざまなタイプのリソースを処理するように設計されているため、意図的に高レベルに抽象化されます。

RESTの仕様は、APIがごく最近使用し始めたばかりですが、かなり前向きです。

RESTプロトコルについて詳しく知りたい場合は、「Haters Gonna Honna HATEOAS」を読むことを強くお勧めします。

更新：

@Shaunaは私の推論に興味深い穴を指摘しました。真の正しい方法はなく、多くの形式が受け入れられると考えられています。もう少し考えましたが、データを別の表現に変換するのが目的なので、変換を新しいMIMEタイプとして定義するのが理にかなっています。

たとえば、URIを次のように表すことができます。

/customer/{id}+print

応答のContent-Typeをtext / html + printに設定できる場所。そうすれば、将来、より多くの変換を定義するオプションもあります。

例えば：

// for application/json
/customer/{id}+json

// for application/atom+xml
/customer/{id}+atom

どちらの方法でも、すべてのフォームが受け入れられます。決定する実装は、個人の好みとサーバーの機能にさらに依存します。

余談：混乱があるようですので、明確にさせてください。リソースの変換方法を指定するには、「print」クエリパラメータまたはコンテンツタイプ、あるいはその両方を使用します。物理的な印刷ジョブをトリガーする方法ではありません。セキュリティ上の理由から、ハードウェアレベルのアクセスは常にユーザー/クライアント/ブラウザーに任されています。