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 回答