1

API に次の機能があり、いくつかの質問に出くわしました。

  1. POST /user (フルネーム、電子メール、パスワードが必要) は新しいユーザーを作成します。ユーザーが作成されている場合、一意のアクティベーション ID が生成され、アカウントをアクティベートするためのリンクがメールでユーザーに送信されます。

  2. PUT /user (ID、電子メールが必要) は、ユーザーをアクティブにします。

ユーザーがアカウントをアクティブ化すると、ログインできます。

  1. POST /session (電子メールとパスワードが必要) を実行し、ユーザーにログインします。
  2. GET /session は Cookie セッション ID を調べ、認証されている場合はユーザー情報を返します。
  3. DELETE /session は、ユーザーをログアウトさせます。

ユーザーがログインすると、興味 (HTML テキストエリアのみ) を送信するように求められ、アカウントに関する説明 (場所、性別など) も送信できますが、すべてオプションであるため、Twitter アカウントのような HTML テキストエリアも送信できます。説明)

今私の質問は:

ご覧のとおり、2. PUT /user はユーザーをアクティブにしますが、適切な安らかな設計で送信された興味とアカウントの説明をどのように処理すればよいでしょうか?

バックエンドサーバーで PUT /user が入ってきて、送信されたフィールドを検出するポイントを確認する必要がありますか?

または、別の PUT /user/activate と PUT /user/interests を作成する方が理にかなっているでしょうか。

これが完了したら、復元パスワードで展開したいと思います。また、これは PUT /user であり、サーバー側でのフィールド検出がややこしくなるのではないでしょうか?

バックボーンについては、これが私のセッション モデルです。

var Session = Backbone.Model.extend({
  url: '/session'
});

var session = new Session();
session.fetch(); // Get the user authentication of the backend server.

私のユーザーモデル:

var User = Backbone.Model.extend({
  url: '/user'
});

function signup(fullName, email, password){
  var user = new User();
  user.save({
    fullName: fullName,
    email: email,
    password: password
  });
};

function activate(id, activationId){
  var user = new User();
  user.save({
    id: id,
    activationId: activationId
  });
};

// Possibility...?
function submitInterests(id, interests){
  var user = new User(url: '/user/interests/');
  user.save({
    id: id,
    activationid: activationId
  });
}

読んでくれてありがとう。

4

1 に答える 1

1

RESTful な世界での経験則は次のとおりです。

動詞を下に、名詞を上に。

これは、すべてのアクションに魔法の 4 [ ]GET, POST, PUT, DELETEで十分なはずだからです。/users/activate/user/edit

アクティベーションのためPUTに全体を作成することは正当に思えるかもしれませんが、「entity = users、id = 3、...」などにすべてのリクエストを送信して渡すことになります。/users/root

コレクション [新しいものを作成/entitynameできる場所]に使用し、単一のエンティティ [この場合は単一のユーザー] を参照するために使用することをお勧めします。POST/entityname/:id

これで、必要なことを何でも達成PUTすることができます。/users/123


もちろん、リソースをネストできます:

/users/:id/interests

:id-thこれは、ユーザーのすべての関心に対するルートです。 を発行GETしてすべてを取得したり、POSTをリストに要素を追加したり、すべてのリストを最初からPUT設定したりできます。


リソースについての最後の考えsession: 真の RESTful サービスは * statelessであるべきです。つまり、セッションに依存すべきではありません。承認はリクエストごとに行う必要があります。HTTP Basic Authを参照してください。

/user/:id/sessionsスキーマとの一貫性を保つために、新しいログインを作成できるリソースを定義POSTできるため、ユーザー アクセスを追跡できます。

于 2012-09-11T23:33:57.780 に答える