Question

好吧，我已经负责这个RESTful架构的服务器和客户端（内部使用）。（使用restlet）。

我们有一个公开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;
    }

}

反过来又使用另一个复杂对象（Profile）

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;
    ...

使用了很多复杂的类型等等。

这种复杂类型的使用真的让我感到困惑。我要么不知道如何记录这个（除了制作这些复杂对象内部属性的长列表）或者我只是丢失了。

我的问题是：我需要简化吗？这个架构设计得很差吗？是否有一些构建器方法可以解决这个问题？

Answer 1

通过在客户端和服务器之间共享域实体类型，您（没有具体说明）已经彻底击败了REST。 RESTful系统应该只共享媒体类型和链接关系。使用SOAP可以更轻松地共享类型，因为WSDL允许工具包处理保持客户端和服务器类型同步的详细信息。

REST就是减少客户端和服务器之间的耦合，使它们能够独立发展。显然，如果你有一大堆共享类型，这将很难，这就是为什么你现在有这种不好的感觉。

我解决这个问题的方法是定义两种媒体类型。一种是通用实体数据容器。我们称之为BusinessDocument，另一个称为BusinessLayout。客户端使用BusinessDocument从服务器检索所有数据，BusinessLayout提供“数据绑定”信息，以便客户端知道在我的UI中显示不同业务数据的位置。

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

Answer 2

没有必要将java客户端提供给外部消费者。您的API应该能够回答任何Http客户端。存在共享对象的Java客户端的事实可能取决于不同的因素，但不应影响您将REST API暴露给第三方使用者的方式。

因此，我建议使用apache commons HTTP开始编写纯HTTP客户端，以了解REST API的行为方式。

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

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

宁静的架构问题（太多）复杂的对象

2 个答案: