あなたのバックエンドは二つのモデルがありますモデルに1：Mの関係がある場合、REST URL？これはこれまで私が考えていたものです：REST URLデザインは
/companies/
/companies/<company_id>/
/companies/<company_id>/employees/
/employees/
/employees/id/<employee_id>/
ここで、One Companyには多くのモデルがあるとふりまとめましょう。 「社員を会社に追加する」に使用するのに最適な名前は何ですか？ URIは、追加を必要としないかもしれない最後の1、除いて、私には罰金を見
/companies/add-employee/
/employees/add-company/
：GETを使用して
：
POSTを使用して
/companies/<company_id>/add-employee/<employee_id>/
/employees/<employee_id/add-company/<company_id>/
私はいくつかの選択肢を考えることができますパスの "id"。また、私は言葉の単数形を好むが、それはおそらく私だけです：
/company/
/company/<company_id>/
/company/<company_id>/employee/
/employee/
/employee/<employee_id>/
URIはそれほど実際には関係ありませんし、適切に行わとき、後の任意の時点で変更することができます。つまり、すべてのURIは、クライアントにハードコードされているのではなく、リンクされています。従業員のいくつかの表現で
PUT /employee/123
：限り従業員を追加するように、私はおそらく、上記で定義された同一のURI、およびPUT方法を使用する
。それはidempotentなのでPUTが好きです。これは、操作が失敗した場合（タイムアウト、ネットワークエラーが発生した場合など）、前の操作がサーバー上で「本当に」失敗したかどうかを確認せずに操作を繰り返すことができることを意味します。 PUTは、サーバー側でいくつかの追加作業が必要であり、（フォームなどの）適切にリンクするいくつかの追加作業が必要ですが、より堅牢な設計を提供します。
代わりに、あなたは、本体として、従業員の表現で
POST /employee
を使用することができます。これは保証を提供するものではありませんが、実装が簡単です。
GETを使用して従業員（またはそのようなもの）を追加しないでください。これは、HTTP Specification for the GET methodに対して行われ、純粋な情報検索方法でなければならないと述べています。