問題タブ [restful-url]

モデリング フォーラム グループと投稿のデザインは十分ですか?

1. グループ URL http://www.example.com/groups/soccer

2. 投稿 URL http://www.example.com/groups/soccer/posts/123.html

より良い提案はありますか？

WCFWebAPIを使用してRESTfulサービスを作成するWebサービスがあります。このサービスでは、コンマで区切られたURLパスにさまざまな値が含まれている必要があります。この方法は、誰かの名前や数値などの単純なデータに対して完全に機能します。ただし、クライアント側（JavaベースのBlackBerryアプリ）にフィールドがあり、ユーザーは。などの文字を含むデータを自由に入力できます。または/これは私のURL全体を台無しにします。

文字を16進値（たとえば/から％2F）に置き換えても、問題は解決しません。

アドレスを探すときに無視されるURLでこれらの文字を表す方法、または引用符が機能する方法で次の文字を無視するようにURLに指示する方法を知っている人はいますか？

こんにちは私は安らかなプロジェクトを持っており、クライアント側から休憩を取ります。ただし、場合によっては、サーバー側から安らかな呼び出しを行う必要があります。どうやってやるの？

注文アプリケーションを想定すると、ユーザー「Ben」は次のコマンドを発行して特定の注文をリストできます

/オーダー/1

今..それを行う前に、「Ben」を認証し（ユーザー名/パスワード認証）、ユーザー名をCookieとして送信しました（sha1チェックサムで署名されました）。

httpリクエストごとに、「Bent」がまだ認証されていることを示すCookieを受け取りますが、誰が彼の発行を止めることができますか

/オーダー/23

ここで、id=23 の注文は「Ben」に属していません。

だから私は注文23が実際に「ベン」に属していることを確認するためにいくつかのロジックを書くべきだと思います...それはこの種の状況のベストプラクティスまたはパターンですか?

シリアル主キー ID の代わりに、別の「機能主キー」を使用する必要がありますか?

あるフォーマットから別のフォーマットへの変換を実行するサービスを作成しています。変換の例としては、通貨、距離、時間、言語などがあります。この場合、地理的なポイントです（たとえば、10進角の緯度/経度から度-分-秒の緯度/経度まで）。

通常、RESTfulリソースには、CRUDできるサーバー側で永続的な類似のOOコンセプトがあります（これは、RESTfulを作成するものの一部にすぎないことを私は知っています）が、物事を変換する単純なサービスの場合、そうではありません必ず存在します。どのようにしてこれをRESTfulにするのでしょうか？現在、次のようなものがあります。

サポートされているフォーマットのリストを取得するには、次のようにします。

これは、たとえばDDやDMS（10進数の度と度-分-秒）を含む形式のリストを返します。

次に、向きを変えて、次のように変換を実行できます。

この例では、要求の本文で小数度の表現（JSONまたはその他の形式として）を渡し、応答の本文で度-分-秒の表現を受け取ります。

これはもちろん機能しますが、特に同じURIが異なる入力（異なる小数点以下の桁数）に何度も使用されるため、RESTfulではないと感じます。秘訣はおそらく、操作されているリソースに本当に集中することです。おそらくその「変換」：

本文は、値、その形式、および目的の出力を取り込む場合があります。ただし、URIはすべてのリソースで同じです...

考え？

私は Web アプリを設計していましたが、API を RESTful Web サービスとしてどのように設計するかを考えるのをやめました。今のところ、私の URI のほとんどは一般的なものであり、さまざまな Web アプリに適用される可能性があります。

SOとGoogleをいじった後、私はここで多くのことを間違っていると感じています。

から始めて/logout、おそらく私は実際には何もしていないので、へのリクエスト、セッションの破棄、そしてリダイレクトGETがより適切かもしれません。そして、その用語はとどまるべきですか？POST/logoutGET/logout

/loginとはどうですか/register。/registerに変更することはできます/registrationが、それによってサービスの基本的な動作が変わることはありません (より深刻な問題がある場合)。

/userリソースを公開しないことに気付きました。それが何かに生かされるのかもしれません。たとえば、ユーザーを取りますmyUser:

また

エンド ユーザーは、URI で余分な冗長性を必要としません。しかし、どちらが視覚的により魅力的ですか?

この REST ビジネスに関する SO に関する他の質問に気付きましたが、可能であれば、ここで説明した内容についてのガイダンスをいただければ幸いです。

ありがとう！

アップデート：

また、次の点についても意見をお願いします。

対

さまざまなドメイン オブジェクトに CRUD 操作を提供する RESTFul サービスの設計に取り組んでいます。そのようなオブジェクトの 1 つが Person です。

次のサービスがあります。

タイプが幼児のすべての人に応答します。

ペイロード内の人のリストを受け入れ、それらのレコードを作成します。

質問: 理にかなっていますか?

その場合、ペイロードで渡された人を作成してから、幼児タイプのすべての人のリストで応答しますか?

ベストプラクティスは何ですか?

リソースは、複数の URI で識別できます。例えば

上記のすべてにリソースが含まれる場合があります: Person -

John Doe の年齢を 10 歳から 15 歳に変更したいとします。次のように /person/1234 に PUT します。

クライアントに他の 2 つの URL を強制的に無効にするにはどうすればよいですか?

リソース編集パスが安静な Web アプリでどのように見えるか知っていますか?

深刻な参考文献は見つかりませんが、Ruby on Railsのやり方は単なる慣例です。

リソースを更新するために使用される put リクエストについて話しているのではなく、通常、フォームなどをユーザーに返し、リソースを更新する最終的な put リクエストを作成して送信できるようにするパスです。

前述のRuby on Rails の方法の例は、次へのgetリクエストです。

これを良いアプローチにする深刻な参照や説明があるかどうか疑問に思っています。

安らかな Web サービスで User のインスタンスにアクセスするには、URL は以下の curl リクエストに示すように構成されます。

データベース内の最初の 50 人のユーザーなど、一連のユーザー エンティティを介してすべてのユーザー エンティティまたはページを指定したい場合、REST に準拠するようにリクエストをどのように構成しますか ???