3

好的,我已经负责这个 RESTful 架构的服务器和客户端(内部使用)部分。(使用restlet)。

我们有一个公开 Post 操作的资源。这是一个简化版本:

public class UserResource {

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

几个月来,我们一直是唯一使用这些服务的人,因此域对象在客户端和服务器端共享......而且它工作得很好。

现在我们必须记录这些资源并让其他客户使用它们,一些“问题”已经出现,让我觉得这个 API 可能有点太复杂了。

例如,此 Post 服务。内部方法接受复杂类型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 系统应该只共享媒体类型和链接关系。使用 SOAP 共享类型要容易得多,因为 WSDL 允许工具包处理保持客户端和服务器类型同步的细节。

REST 就是要减少客户端和服务器之间的耦合,以允许它们独立发展。显然,如果您有大量共享类型,那将是困难的,这就是为什么您目前有这种不好的感觉。

我对这个问题采取的解决方案是定义两种媒体类型。一种是通用实体数据容器。我们称它为BusinessDocument,另一个称为BusinessLayout。客户端使用 BusinessDocument 从服务器检索所有数据,而 BusinessLayout 提供“数据绑定”信息,因此客户端知道在我的 UI 中的何处显示不同的业务数据。

通过这样做,我能够构建一个真正不了解它正在处理的数据细节的客户端,它只知道如何在 UI 上显示它以供用户交互。通过这样做,我可以使用一种媒体类型来描述数百个不同的业务实体。

于 2011-06-22T11:24:15.333 回答
0

无需将 java 客户端提供给外部消费者。您的 API 应该能够响应任何 Http 客户端。有一个共享对象的 java 客户端这一事实可能取决于不同的因素,但不应影响您如何将 REST API 公开给第三方消费者。

所以我建议开始编写一个纯 HTTP 客户端,使用 apache commons HTTP,看看你的 REST API 是如何工作的。

服务器对象很复杂这一事实也不应该引起 API 的任何兴趣。如果旧系统是围绕数据设计的建模对象,我认为这是一个坏主意,那是你必须处理的事情。从 REST API 中,您总是只收到文本、XML 或 JSON,并且您最终必须将其解析为您的 Java 对象,例如,如果您有 ORM + RDBMS 支持的系统。如果您可以将 Json 存储在文档数据库中,那么您就不会有这个问题,但同样,这与 REST API 本身无关,但您需要一个将 JSON 转换为 Java 对象的层。

Restlet 可以帮助您解决这个问题,当然,这样复杂的对象并不是一件容易自动转换的对象。

于 2011-06-23T17:25:02.100 回答