4

ユーザーストレージとしてJava APIでStormpathを使用することを考えています。

ユーザーを検索できないことを除けば、良さそうです。

たとえば、次のエラーが表示されます。

Exception in thread "main" com.stormpath.sdk.resource.ResourceException: HTTP 400, Stormpath 2105 (http://docs.stormpath.com/errors/2105): Account ID is not a supported query property.

このクエリを実行すると:

HashMap<String, Object> queryParams = Maps.newHashMap();
queryParams.put("ID", "4mPXXXXXXXXXX");
searchResult = application.getAccounts(queryParams);

ただし、電子メールによるユーザーの検索は機能します。customData プロパティに保存したログイン トークンでユーザーを検索しようとすると、同じエラーが発生します。

クエリできるプロパティは電子メールとユーザー名だけであるように見えるため、私がやりたいことは不可能のようです。しかし、機能しない場合、なぜ彼らはこの機能を提供するのでしょうか。私は何が欠けていますか？

4

1 に答える 1

7

一般的なリレーショナル データベースの動作と REST API の動作との間にはインピーダンスの不一致があります。ID によるクエリは、リレーショナル データベースでは一般的ですが、REST API (またはほとんどの HTTP ベースの Web サイト) では慣用的な動作ではありません。URL (href) は、Web 上のリソースへの正規の「ポインタ」です。つまり、REST API では、正規の識別子はhref です。href 内のすべてのトークン (内部の「id」、特殊文字など) は、REST クライアントに対して不透明であり、クライアントによって完全に無視される必要があります。URL は HTTP と REST の王様です。

そのため、Stormpath SDK は RESTful のベスト プラクティスに忠実であるように努めているためclient.getResource、href と、href が表すと予想されるオブジェクトのタイプを受け入れるメソッドを使用して、Stormpath リソースを取得できます。

String href = "https://api.stormpath.com/v1/accounts/" + id;
Account account = client.getResource(href, Account.class);

client.getAccount(String id)とはいえ、たとえばID の概念を維持したい場合など、これをクライアント API でより便利に表現したいと思うことに問題はありません。その場合は、新しい機能のリクエストを開いてください。喜んで検討させていただきます。

クエリ可能Accountなプロパティについては、こちらに記載されています。Stormpath は、まもなくカスタム データのデータも検索可能にします。Stormpath 機能のタイムラインが発表されることはありませんが、これは同社のエンジニアリングの最優先事項であり、間もなくリリースされる予定です。

一部の人にとって役立つ回避策の 1 つは、アプリケーションで使用しないアカウント フィールドに検索するデータを保存することです。たとえば、「ミドルネーム」フィールドを使用して、好きな色などを保存できます。これは、カスタム データ検索が利用可能になるまでの一時的なものです。チッ！

于 2015-01-25T17:46:13.400 に答える