非CRUDアクション用のREST APIデザイン。保存、デプロイ、コードの実行

Question

私のREST APIコンテキストのリソースはアプリケーションコードであるプログラミング言語で書かれています。 HTTP動詞に簡単にマッピングできるCRUD操作は、コードの保存/編集/削除です。 HTTPメソッドにマッピングするのが難しいCRUD以外の操作は、コードをサーバーにデプロイし、コードを実行し、デプロイ解除します。私が出会った

一般的な提案はSOます：

1. 再構築アクションはリソースの分野、例えばのように表示されるようにあなたの行動がエンジンを起動する場合は、URI：PATCH engines/123、本文：{"status":"active"}
2. アクションをサブリソースのように扱います。 PUT engines/123/active本文なし
3. クエリパラメータを使用します。 PUT engines/123?activate=true
4. 実用的であり、RESTfulでないRPCスタイルのURL（例： ＃1、＃2で提案されているようPUT engines/activate?id=123

は、私は間違いなく、リソースへdeploy/undeploy/executeコードアクションに合わせてすることはできませんよ。これらのアクションのためにAPIを設計する最良の方法についてご意見をお寄せください。

Answer 1

これらの操作にAPIを最適に設計するにはどうすればよいですか？

更新/ 情報資源を作成/削除、およびその副作用として、APIの背後で動作します。

ドキュメントだと思います。

1つの非常に良い例：RESTful Causistryでは、Tim BrayがマシンをシャットダウンするためのAPIについて質問しました。 Seth Ladd's response、特に重要です。

基本的に、RESTは事務処理の問題を解決する官僚機構です。あなたが何かをやりたいのなら、正しい形式を提出してください。これはあなたが何をしたいのかを記述する情報リソースになります。

PUT /deploymentRequests/abcde 

Please find the artifacts from build 12345 and deploy that artifact 
to machine 67890 

201 Created 

要求は、いくつかのタスクに対処するためにあなたを求め、あなたの机の上に付箋が文書でまったく同じように、単に文書です。

RESTに関する限り、URIのスペルは絶対に重要ではありません。人間が判読可能な命名規則の観点からは、リソースがドキュメントであることから始めます。ドキュメントに付ける副作用ではありません。

だから、例えば、それは残りの部分と完全に正常で対応だという事の現在の状態を記述した文書、あなたがものにしたいの変更です異なる識別子を持つ異なるドキュメントを記述した文書。