实现基于HTTP，XML的CRUD Layer是一个好主意吗？

Question

我正在为应用程序制作一个CRUD“图层”。 这将是一个简单的CRUD应用程序，例如，存储用户信息，收藏夹链接等，而不对“事实类型”数据进行操作。它实际上只存储用户，权限，规则，策略等内容，应用程序的其他部分可以执行工作。

总的来说，我想要做出三件事：

• （a）访问CRUD功能的单一入口点
• （b）能够使用任何“客户”来使用CRUD层
• （c）CRUD的“简单”可扩展性，其中可以添加新对象并且可以更改旧对象（添加新字段，不删除或更改任何其他字段）。一个典型的CRUD场景？

我在想我应该创建一个Java库，通过“REST-type-URL”将其暴露给客户端（意思就是REST-URL-way，比如“users / delete / 2”）API通过HTTP。这样，我可以满足所有3个目标 - CRUD层可以在Linux上，客户端可以在Windows中。

在CRUD层，我将使用各种方法来实现这一目标：ORM，网络服务器和其他工具。

似乎正确的方式，但我不禁想知道这种方法可能过于理想化，在我开始实施时可能无效。

我正在考虑将一组API方法塞进XML片段中做一些过于简单化的观点吗？ （请注意，我没有使用XML-RPC，而是这些XML片段只是数据 - 并且XML将被发送到特定的URL，例如users / update / 2，它将在确认之后处理XML XML包含用户配置文件的信息）

我的思考是否正确？这个想法是否有远程工作的机会？

任何帮助表示赞赏！

Answer 1

是的，它会起作用。但是，您假设数据模型非常简单并且将保持这种方式，那么您的设计基于分布式系统。如果您正在构建的应用程序成功，则可以确保添加新要求并请求新功能。

按照您的建议公开数据层，将客户端应用程序紧密地耦合到数据模型，并且使用http会使进行多请求事务变得非常困难。我知道你说你不需要做多请求交易。不是今天，但也许是明年？

此应用程序的预期寿命是多少？如果你说超过几年，那么我会重新思考将数据层暴露给远程客户端的想法。 REST的主要目标之一是解除客户端和服务器应用程序的分离，以允许应用程序在很长一段时间内发展。如果您有多个客户端应用程序访问分布式服务，如果设计不正确，它可能会很快遇到令人讨厌的维护和版本控制问题。

编辑以回答有关客户需要了解模型的评论中的问题：

关于客户端如何与从服务器接收的表示进行交互，您可以采取两种不同的指示。

1. 您可以允许客户端明确了解表示中包含的数据内容。即客户端知道某些XML元素中存在用户名和密码。但是，如果您这样做，您应该返回特定的媒体类型，例如应用/ vnd.mycompany.user + XML。您不应该使用application / xml，因为它不会告诉客户端有关XML文档中的内容的任何信息。如果客户端知道“当你转到url X”时，你会得到“一个包含元素UserName和Password元素的Xml文档”，那么你就违反了REST的自我描述性约束。影响是您已将端点耦合到媒体类型，并且实际上将客户端耦合到该端点。 REST的“超媒体约束”的目的是防止客户端和端点之间的耦合。
2. 另一种方法是使用更通用的媒体类型，该媒体类型仅用于向客户端提供要向用户显示的内容，并向用户提供允许客户端采取操作的选项。 html媒体类型允许您通过提供可用于在两个div标签中返回用户名和密码的标记语言来执行此操作。使用html FORM标记和A标记，客户端可以对该资源执行其他操作。弄清楚如何以真正的REST方式使“用户”对象可能拥有的所有可能操作变得棘手并且需要相当多的经验，但最终结果是一个非常好的分离的客户端和服务器。以Web浏览器为例，您需要多久进行一次浏览器更新，因为网站已经更改了内容。

第二个选项的问题在于，仅使用HTML，最终用户体验往往受到很大限制，这就是Javascript的用武之地。其中一个“可选”REST约束是代码下载。 Javascript是从服务器加载的代码，用于在客户端上启用其他行为。不幸的是，在我看来，它还为人们提供了创建返回application / xml的RESTful Web界面，然后使用javascript来解释该通用格式的能力。此解决方案适用于使用RESTful API的网站的原始开发人员，因为如果xml文件的内容发生更改，则javascript可以更改并重新下载到浏览器，一切都很好。但是，对于访问此API且不受应用程序/ xml内容模型控制的任何其他第三方开发人员，其代码将变得非常脆弱，并且如果API内容发生更改，则可能会中断。询问任何为Twitter撰写任何类型客户的人，他们的应用程序因Twitter改变了内容而破坏了多少次。

通过使用第一个选项并为内容提供特定的媒体类型，服务器开发人员可以引入一个名为application / vnd.mycompany.userV2 + xml的新媒体类型，并使用内容协商，现有客户端仍然可以接收原始媒体可以构建类型和新客户端以使用新媒体类型。网址保持不变，书签不会被破坏，因为端点和媒体类型没有耦合。

如果您看到API文档提供了Url列表以及从这些URL返回的内容，那么开发人员可能无法获得REST并且无法获得RESTful接口提供的好处。具有讽刺意味的是，并不是那些遭受最大痛苦的开发者，第三方尝试与API接口会受到影响！

Answer 2

对于纯数据层，您是否考虑过事务支持？

• 您需要支持交易吗？如果是这样，它们将如何实施？
• 事务是否会跨越多个HTTP请求？ （我认为对于一个纯REST实现，你会有多次调用非平凡的操作。）例如借记一个帐户并记入另一个帐户。
• 谁来控制交易？

如果现在不需要交易控制，你能否在将来看到它？这会如何影响您的设计？

问题多于答案。 :)但值得深思。

更新：

我将使用您选择的语言（在您的Java案例中）和您需要的任何其他库（例如ORM）创建标准数据访问层。如果您已经有数据访问层设计，我会遵循这一点，以保持应用程序的简单。如果你想在外部公开这个（给不同的客户端），我会在我称之为服务/业务层的方面做这件事（如果功能很简单，没有重用的可能性，那么将一个实现都折叠起来可能就行了）。在那里，您将处理任何安全性（身份验证，授权等），数据验证，并可能执行内部数据表示和外部表示之间的任何映射。然后，您可以根据基于URL的API公开您的服务。这使您可以在实际的数据访问实现和界面之间进行一些分离。

也许我们在谈论同样的事情，但我们的语义只是不同。

Answer 3

如果您想从多个客户端访问CRUD功能，这是一个好主意。我们已经做了类似的事了一段时间。一些可能对您有帮助的实施细节。

1. 简单的HTTP调用就足够了，不要为REST烦恼。要成为RESTful，您必须遵循以下规则（GET for READ，PUT for create等）。只需使用GET即可在浏览器中轻松测试。我们使用XSLT将响应格式化为HTML格式的表格。

2. 我们使用一个XML架构来处理所有响应。它基本上是SQL结果的XML表示，它应该足够灵活，可以处理多个结果集，受影响的行，错误响应，返回代码等。

3. 拥有XML的JSON表示，以便在Javascript中更容易处理。

4. 我们还添加了一个SQL后门，因此可以将任意SQL语句发送到数据库。这对于调试非常方便。这种呼叫需要一些安全性。我们只将其暴露给办公室网络。

Answer 4

如果您正在寻找Java解决方案，我建议您查看Restlets。 您几乎将XML-RPC和REST样式架构混合在一起。 Here是RPC和REST之间的区别 如果要以RESTful方式执行，则应使用URI来确定操作和参数，而不是传递XML。