Java 直接向WebClient公开webservice，还是在两者之间保留一个精简的服务器端脚本层？

我正在开发一个RESTWebService（Java，Jersey）。我为之工作的人希望通过Javascript直接访问Web服务。有些本能告诉我这不是一个好主意，但我无法真正解释这种本能。我的自然方法是让webservice执行真正的逻辑和数据库访问，但也有一些（相对较薄的）服务器端脚本层（例如PHP）。客户端将与PHP层通信，而PHP层又将与Web服务通信。（Web服务对于apache/PHP服务器来说是非常本地的，并且隐式信任来自脚本层的调用。脚本层负责会话管理。） （顺便说一句，我不是说仅仅将Web服务隐藏在Apache后面，Apache只是重定向调用。）

但当我发现自己缺乏文字/论据来解释我的直觉时，我怀疑我的直觉是否正确——请注意，虽然我已经用各种语言和框架开发了各种软件17年，但这是我第一次开发Web服务

所以我的问题基本上是：你的观点是什么？有任何标准设置吗？我的直觉完全错了吗？还是部分；P

非常感谢,

马克斯

PS：我可能会添加一些关于整个应用程序计划使用情况的信息：

• 将被不同类型的用户访问，部分是普通用户，部分是特权用户
• 因此，所有主要的操作系统/浏览器组合都可以作为客户端
• 然而，写客户不是我的责任
• 可能会有非常高的负载/流量
• webservice的逻辑稍后将为另一个产品进行大规模扩展，该产品基本上是当前项目功能的超集
• 很有可能在某个时候公开一个API，第三方开发人员可以使用它——显然，有一些限制
• 在某种程度上，公众对该产品的看法也应该可以通过智能手机访问（换句话说，可能是一个定制版本的网站，以适应更小的显示和不同的输入方法）

---

我不认为通过JavaScript等直接访问REST Web服务是正确的 一般来说，这是一个坏主意，因为REST体系结构就是这样设计的 对于对于您的用例，您可能需要考虑一些含义：

• 您的Web服务必须负责用户管理。由于REST体系结构不支持服务器端会话状态，因此必须对每个请求进行身份验证和授权。用户必须在客户端维护其状态
• 您的webservice实现必须处理缓存和负载平衡等问题，以及您可能分配给PHP“代理”脚本的所有其他事项

根据您的要求：

所有主要的操作系统/浏览器组合都可以 被视为客户

由于webservice只提供数据（例如JSON或XML），所以这应该不是问题。JavaScript部分只需注意发出正确的请求

可能会有非常高的 载客量/交通量

如果严格遵循REST体系结构，则可以使用http缓存。但是请记住，无状态的特性总是会导致更多的流量

webservice的逻辑将在稍后讨论 为另一种产品大规模扩展 这基本上是 当前项目的功能

开放式Web服务的好处是可以将它们松散地耦合在一起

很有可能 在某个时候，API应该公开 可供第三方使用 开发人员-显然，有一些 限制

同样，使用RESTfulWebService，您已经为开发人员公开了一个API。这是好事还是坏事，由你的客户来决定

在某种程度上，公众对 产品应通过 智能手机

---

另一个使REST Web服务可公开访问的专业人士。大多数智能手机API都支持HTTP请求，因此您只需为直接调用Web服务的特定smarphone平台开发GUI即可。

首先，我只是扩展了Daff上面的回答。我从学习、设计和实现RESTful Web服务的角度扩展了Daff的回答，请注意，我还在学习

当我开始使用Java、Jersey（0.3IIRC）学习RESTful WS时，我也遇到了类似的问题，其主要原因是对RESTful体系结构的“完全”误解。我犯的最“严重”的错误是直接从/到持久性bean使用JAXB进行XML和Jackson进行JSON（反）序列化。这完全违反了REST原则，因此在创建高性能、高可用性、可扩展的web服务时产生了一些重要问题

我的错误是，从API a.k.a服务的角度考虑，当我们考虑RESTful WS时，我们应该忘记“API”，而考虑资源。我们应该非常注意资源的互联。我是在阅读之后才理解这一点的，我建议任何想要创建自己的web服务的人使用它。我的结论是，资源对于RESTful WS/Architecture来说，就像API对于本机接口或SOAP Web服务一样重要。因此，我建议您谨慎地设计资源，并理解您的Web服务可能拥有的资源没有限制

下面是我在实现通过RESTful WS公开“API”的系统时得出的结论。我创建了一个处理与业务实体通信的API，例如PersistentBook，它包含PersistentAuthor的Id或对象本身。所有考虑持久实体的业务逻辑都位于API实现层

<