2016-05-25 2 views
3

私はエンティティTemperatureを持っています。次のように私のURLが設計されていオブジェクトの収集のためのRESTful URL

GET  /api/temperatures/new 
GET  /api/temperatures/{id}/edit 
GET  /api/temperatures 
POST  /api/temperatures 
PUT  /api/temperatures/{id} 
DELETE /api/monitoring/temperatures/{id} 

私は一度に複数の温度(温度のコレクション)を作成したいと思います - 使用するURLの条項のいずれかの規則がありますか。

はこれまでのところ、私は、次のを思い付いた:

POST /api/monitoring/temperatures/collection 
GET /api/monitoring/temperatures/cnew 

私はまだあなたに確認したいと思い、このための規則がなければならないと思いました。

+0

'/ api/temperatures'エンドポイントに' POST'を使って温度配列を送信してみませんか? –

答えて

0

HTTPメソッドGETは、リソースの作成または編集には適しません。/api/temperatures/newおよび/api/temperatures/{id}/edit。 HTTP GETは、サーバーの状態を変更せずに情報を取得するために使用されます。 use POST or PUTする必要があります。

あなたが複数の温度を作成する場合は、

POST /api/monitoring/temperatures 

を使用してJSONまたはオブジェクトのXMLリストを消費する必要があります。

Javaの例:

@POST 
@Path("/temperatures") 
@Consumes(MediaType.APPLICATION_JSON) 
@Produces(MediaType.APPLICATION_JSON) 
public Response postTemperatures(Temperatures temperatures){ 
    // process and save 
} 

@XmlRootElement 
public class Temperatures { 

    public List<Temperature> temperatures; 

    Temperatures(){} 
} 
3
GET  /api/temperatures # Getting all resources 
POST /api/temperatures # Create new resource 
GET  /api/temperatures/<id> # Get a single resource 
PUT  /api/temperatures/<id> # Edit all fields 
PATCH /api/temperatures/<id> # Edit some fields 
DELETE /api/temperatures/<id> # Delete a resource 

これらは、URLのフィールディングは、RESTに彼の論文に記述の種類があります。エンドポイントがURLで何をしているのかを記述するべきではありません。特に、HTTP動詞が適切に使用されていると、十分な情報が得られます。 RESTのアーキテクチャー・スタイルは、HTTP経由のJSONよりも多くのことを持っていることに注意してください。一般的なコネクタ、コンポーネントのデカップリング、ステートレス・サーバーは、RESTfulアプリケーションの重要なコンポーネントです。

注:ほとんどの人は、PUTとPATCHの両方を実装していない可能性があります。 PUTは問題ありませんが、私はそれを完全性のために含めました。

あなたのコメントに応じて、1つのPOSTリクエストで複数のリソースを作成することを指している場合、新しいURLは必要ありません。アプリケーションは、同じエンドポイントで{temp: 45, date: ...}[{temp: 45, date: ...}, {temp: 50, date: ...}]を処理できる必要があります。

+0

ありがとう@IanAuld何をお勧めしますか? – Mick

+0

何をお勧めしますか?複数の新しいリソースを作成する必要がある場合は、複数のPOSTを送信するか、新しいリソースを含むPOST要求を処理できるようにする必要があります。 – IanAuld

+0

素晴らしい - 2番目のシナリオではどのURLを投稿しますか? – Mick

0

あなたは、代わりに、単一のエントリの温度の配列に送信することにより、単一のポストを持つ複数のエントリを更新することができ

POST  /api/temperatures { [{...},{...}] } 

が、あなたのAPIエンドポイントの構造が少し合理化することができます。

理想的には、すべてのAPIリソース用にシンプルな一貫したインターフェイスが必要です。

私は個人的に簡素化します:

GET  /api/temperatures/new 
GET  /api/temperatures/{id}/edit 
GET  /api/temperatures 
POST  /api/temperatures 
PUT  /api/temperatures/{id} 
DELETE /api/monitoring/temperatures/{id} 

GET  /api/temperatures   // Get all temperatures 
POST  /api/temperatures   // Send in array of new entries to update 
GET  /api/temperatures/{id}  // Read a specific temperature 
PUT  /api/temperatures/{id}  // Update a specific temperature 
DELETE /api/temperatures/{id}  // Delete a specific temperature 

にこれはCRUDインタフェース上にマッピングし、すべての温度関連の呼び出しのためのAPIへの一貫したインタフェースを提供します。

コンテキストがなければ、正確には/ api/temperatures/newが使用されますが、レスポンスを細かく設定するためにパラメータを使用することを検討します。

/api/temperatures?age=new  // Get new temps 

共通構造を使用して、後でさまざまな種類の基準を追加することができます。

関連する問題