3

さて、私はこの RESTful アーキテクチャのサーバーとクライアント (内部で使用される) の両方の部分を担当しています。（レストレットを使用）。

Post 操作を公開するリソースがあります。簡略版は次のとおりです。

public class UserResource {

    @Post
    public Representation create(UserRegistration registration) {
        SomeService.getInstance().createUser(registration);
        return new XstreamRepresentation(new RegistrationResponse(registration.getUniqueCode()););
    }

数か月間、これらのサービスを使用していたのは私たちだけだったので、ドメイン オブジェクトはクライアント側とサーバー側で共有されていました...そして問題なく動作しています。

これらのリソースを文書化し、他のクライアントがそれらを使用できるようにする必要があるため、いくつかの「問題」が発生しているため、この API は少し複雑すぎるのではないかと思いました。

たとえば、この郵便サービス。内部メソッドは複合型UserRegistrationを受け入れます

public class UserRegistration implements Serializable {

    private Profile profile;
    private Boolean someBooleanProperty;

    public UserRegistration(Profile profile) {
        this(profile, true);
    }

    public Profile getProfile() {
        return profile;
    }

    public boolean isSomeBooleanProperty() {
        return someBooleanProperty;
    }

}

次に、別の複雑なオブジェクト (プロファイル) を使用します。

public class Profile {

    private String nickname;
    private String email;
    private String password;
    private String firstname;
    private String lastname;
    private Date birthDate;
    private String phone;
    private Address address;
    private GenderType gender;
    private String subscriptionSite;
    private Date privacyAcceptanceDate;
    private Date subscriptionDate;
    private String activationCode;
    private String socialSecurityNumber;
    ...

多くの複雑な型などを使用しています。

この複雑な型の使用は、私を本当に悩ませているものです。これを文書化する方法がわからない (これらの複雑なオブジェクトの内部プロパティの長い長いリストを作成することは別として) か、単に道に迷っています。

私の質問は次のとおりです。単純化する必要がありますか? このアーキテクチャは非常に悪い設計ですか? いくつかのビルダーメソッドでうまくいくでしょうか?

4

2 に答える 2

3

クライアントとサーバー間でドメイン エンティティ タイプを共有することにより、REST のポイントを完全に打ち負かしたことになります (具体的には言いません)。RESTful システムは、メディア タイプとリンク関係のみを共有することになっています。WSDL を使用すると、クライアントとサーバーの型の同期を維持するための詳細をツールキットで処理できるため、SOAP を使用すると、このように型を共有するのがはるかに簡単になります。

REST とは、クライアントとサーバー間の結合を減らして、それらが独立して進化できるようにすることです。明らかに、共有型のセットが多数ある場合、それは困難になるでしょう。それが、現在このような嫌な思いを抱いている理由です。

この問題に対して私が取った解決策は、2 つのメディア タイプを定義することです。1 つは、一種の一般的なエンティティ データ コンテナーです。これを BusinessDocument と呼びましょう。もう 1 つは BusinessLayout と呼びます。クライアントは BusinessDocument を使用してサーバーからすべてのデータを取得し、BusinessLayout は「データ バインディング」情報を提供するため、クライアントは UI のどこにさまざまなビジネス データを表示するかを認識します。

これを行うことで、処理しているデータの詳細を実際には理解していないクライアントを構築できます。ユーザーが対話するために UI にデータを表示する方法を知っているだけです。これにより、1 つのメディア タイプを使用して、何百もの異なるビジネス エンティティを記述することができます。

于 2011-06-22T11:24:15.333 に答える
0

Javaクライアントを外部コンシューマーに提供する必要はありません。APIは、任意のHttpクライアントに応答できる必要があります。オブジェクトを共有するJavaクライアントがあるという事実は、さまざまな要因に依存する可能性がありますが、RESTAPIをサードパーティのコンシューマーに公開する方法に影響を与えるべきではありません。

したがって、REST APIがどのように動作するかを確認するために、apachecommonsHTTPを使用して純粋なHTTPクライアントの作成を開始することをお勧めします。

サーバーオブジェクトが複雑であるという事実も、APIの関心事ではありません。古いシステムがデータを中心にオブジェクトをモデル化するように設計されていた場合、これは悪い考えだと思いますが、それはあなたが対処しなければならないことです。REST APIからは、常にテキスト、XML、またはJSONのみを受け取ります。たとえば、ORM + RDBMSでサポートされているシステムがある場合は、最終的にそれをJavaオブジェクトに解析する必要があります。ドキュメントDBのようにJsonを保存できる場合、この問題は発生しませんが、これもREST API自体には関係ありませんが、JSONをJavaオブジェクトに変換するレイヤーが必要です。

Restletはこれを支援します。もちろん、このような複雑なオブジェクトは、自動的に変換するのは簡単ではありません。

于 2011-06-23T17:25:02.100 に答える