Questions tagged «rest»

我正在启动一个新的Java项目，该项目需要RESTful API。它将是为移动客户提供服务的SaaS业务应用程序。 我已经用Java EE 6开发了一个项目，但是我对生态系统不是很熟悉，因为我的大部分经验都在Microsoft平台上。 对于诸如所述的新项目，对于JAX-RS实现，哪个选择是明智的选择？ 从维基百科的列表来看，主要竞争者似乎是Jersey，Apache CXF，RESTeasy和Restlet。但是Wikipedia上引用的JAX-RS实现的比较是从2008年开始的。 他们各自的主页给我的第一印象是： CXF的目标是成为一个非常全面的解决方案（使我想起了Microsoft领域的WCF），这使我认为，理解，设置和调试它可能比我需要的更为复杂。 Jersey是参考实现，可能是一个不错的选择，但是它是Sun的遗留产品，我不确定Oracle如何对待它（公告页面不起作用，最后一次提交通知是在4个月前）。 RESTeasy来自JBoss，可能是一个不错的选择，尽管我不确定学习曲线。 Restlet似乎很流行，但是有很多历史，我不确定它在Java EE 6世界中是最新的还是不确定它是否带有沉重的J2EE思维方式（例如许多XML配置）。 这些替代方案的优点是什么？那学习曲线呢？功能支持？工具（例如NetBeans或Eclipse向导）？调试和部署的便利性如何？这些项目中的任何一个是否比其他项目更新？它们的稳定性如何？

35 java  rest  java-ee 

据我目前的了解，HATEOAS基本上是与每个响应链接一起发送以及下一步操作的信息。在互联网上可以轻松找到一个简单的示例：银行系统和帐户资源。该示例显示了对帐户资源的GET请求后的此响应 GET /account/12345 HTTP/1.1 HTTP/1.1 200 OK <?xml version="1.0"?> <account> <account_number>12345</account_number> <balance currency="usd">100.00</balance> <link rel="deposit" href="/account/12345/deposit" /> <link rel="withdraw" href="/account/12345/withdraw" /> <link rel="transfer" href="/account/12345/transfer" /> <link rel="close" href="/account/12345/close" /> </account> 连同数据一起，有链接告诉下一步可以做什么。如果余额为负，我们有 GET /account/12345 HTTP/1.1 HTTP/1.1 200 OK <?xml version="1.0"?> <account> <account_number>12345</account_number> <balance currency="usd">-25.00</balance> <link rel="deposit" href="/account/12345/deposit" /> </account> 这样我们只能存款。很好，如果我们使用Fiddler或通过浏览器发出请求，我们可以轻松地看到可以做什么。这样的信息对于我们发现API的功能以及服务器与客户端的分离非常有用。 但是，要点是，当我们构建客户端（例如带有Javascript的SPA或Android应用程序或许多其他东西）时，我看不到HATEOAS如何继续发挥作用。我的意思是：当我用javascript编码SPA时，我必须知道可以在API中完成什么才能编写代码。 …

35 rest  client-server  hateoas 

我正在一个项目中，我们试图将域驱动设计和REST都应用于面向服务的体系结构。我们不必担心100％符合REST。最好说我们正在尝试构建面向资源的HTTP API（Richardson REST成熟度模型的第2级）。但是，我们试图远离RPC样式的HTTP请求的使用，即，我们尝试根据RFC2616实现我们的HTTP动词，而不是使用POSTdo来实现IsPostalAddressValid(...)。 但是，对此的强调似乎是以我们尝试应用域驱动设计为代价的。只有GET，POST，PUT，DELETE和其他一些很少使用的方法，我们倾向于建立眉头服务和眉头服务往往有贫血的域模型。 POST：接收数据，对其进行验证，然后将其转储到数据中。GET：检索数据，然后将其返回。那里没有真正的业务逻辑。我们还在服务之间使用消息（事件），在我看来，大多数业务逻辑最终都围绕该消息构建。 REST和DDD是否处于某种程度的紧张状态？（或者我在这里误解了什么？我们是否可能在做其他错误？）是否有可能在面向服务的体系结构中构建强大的域模型，同时避免RPC样式的HTTP调用？

34 rest  domain-driven-design  domain-model 

我们的网址格式如下 / instance / {instanceType} / {instanceId} 您可以使用标准的HTTP方法来调用它：POST，GET，DELETE和PUT。但是，我们还有其他一些操作，例如“另存为草稿”或“制作” 我们认为我们可以只使用自定义HTTP方法，例如：DRAFT，VALIDATE，CURATE 我认为这是可以接受的，因为标准说 “下面定义了HTTP / 1.1的一组常用方法。尽管可以扩展此组，但是不能假定其他方法可以为单独扩展的客户端和服务器共享相同的语义。” 像WebDav这样的工具会创建一些自己的扩展。 定制方法是否会遇到问题？我正在考虑代理服务器和防火墙，但是任何其他令人关注的方面都欢迎。我应该放心一点，只是拥有URL参数，例如action = validate | curate | draft？

34 rest  http 

关于HTTP API响应是否有某种标准？ 看完这篇演讲后，我开始怀疑。我们正在工作中开发公共HTTP JSON API，并且在不需要严格要求时不返回任何内容（例如，当/ OK或相应的4XX或5XX代码返回PUT到/ resource / {id}时仅返回200），但是没有JSON正文） 我们应该返回{"success":true}像他们在上面的链接中讨论的那样的泛型，还是可以返回“ void”主体并使用http响应代码处理所有内容？

33 rest  api-design  http 

看这次谈话后的休息，再利用和缘分由史蒂夫Vinoski的，我不知道是否有商业案例在新建项目（基于XML）RPC十岁上下的设置，即REST不能以更好的方式解决。 他提到了一些RPC问题： 专注于语言（使分布式系统适应该语言，而不是相反） “使它看起来是本地的”（并将失败和延迟作为例外而不是规则来处理） 旨在独立于语言，但仍将跨语言的“函数调用”作为主要成分 IDL样板 类型安全的错觉 还有更多... 只是为了生动起见，RPC vs REST的一些Google Instant结果：

33 web-services  rest  use-case  rpc 

在过去的两家公司中，我曾经使用过REST API，用于通过Web应用程序查询数据。即。而不是让Web应用程序直接执行SQL，而是调用REST API，然后执行SQL并返回结果。 我的问题是...为什么要这样做？ 如果它要暴露给第三方，我可以理解。比完整的数据库更好地公开有限的REST API。但是在这两家公司中并非如此。 有人向我建议，这些REST API使在DBMS之间进行切换更加容易。但这不是数据库抽象层（DBAL）的重点吗？也许您将ORM用作DBAL，或者您可能只编写原始SQL并让DBAL在适当的情况下转换特定于DB的内容（例如，将MySQL的LIMIT转换为MSSQL的TOP）。 无论哪种方式，对我来说似乎都是不必要的。而且我认为这也使诊断问题变得更加困难。如果Web应用程序上的报告给出了错误的数字，则您不仅可以转储SQL查询，还必须转储REST URL，然后进入用作REST API的项目，并从中提取SQL。因此，这是一个额外的间接层，减慢了诊断过程。

32 database  web-applications  rest  web-api 

假设我有一个REST API，该API也用于设置/重置密码。我们还假设它可以通过HTTPS连接工作。是否有充分的理由不将该密码放在调用路径中，也可以说我将在BASE64中对它进行编码？ 一个示例是重设这样的密码： http://www.example.com/user/joe/resetpassword/OLDPASSWD/NEWPASSWD 我知道BASE64没有加密，但是在这种情况下，我只想保护密码以进行网上冲浪。

31 rest  passwords 

据我所知，使用SOAP需要使用SOAP堆栈，因此客户端很难使用，即他们需要确保已拥有适当的SOAP堆栈来正确格式化POST数据和标头，然后为您提供一些数据结构，而使用REST，您只需使用查询字符串中的参数发出HTTP GET请求，然后获取一些我想可能是XML的文本。 那么，SOAP的额外开销/复杂性会给您带来什么呢？什么时候需要它？什么时候可以？

30 web-services  rest  soap 

我正在构建一个REST API，具有不同角色的多个用户将可以访问它所包含的资源。 为了简化范围，让我们采用“学生/教师/班级”域： GET /students 是要访问的资源。 用户可能具有学生和/或老师之类的角色 学生将只能访问其班级的学生。老师将有机会接触所教课程的学生。一些用途可能是学生，也可能教其他课程。他们必须有权访问班级的学生和所教课程的学生。 理想情况下，我希望将其实现为两个功能-每个角色一个，如果用户具有多个角色，则“工会”。 我的问题是：我应该使用哪种模式来实现这一目标？ 在外部 我应该按角色划分API吗？GET /teacher/students而GET /student/students这似乎并不合适的给我。 保留所有这些，我是一种资源（首选） 内部地 应该如何在内部实施？ 每种方法都应该以BIG开关/如果每个角色开头吗？ 我应该为每个角色实现一个存储库吗？ 有没有一种设计模式可以帮助我实现这一目标？ 附带说明一下：我正在使用ASP.NET Web API和Entity Framework 6，但这对于概念性实现来说并没有关系。

27 design-patterns  programming-practices  rest  web-api 

我将着手进行一个广泛使用正确的RESTful方法的项目。也就是说，它使用HATEOAS并以允许客户端进行常规探索的方式提供资源。 我想确保以一种允许以多种语言自动生成客户端应用程序的方式提供对端点的描述。我了解对于基于SOAP的Web服务，我可以使用WSDL，并且显然有WSDL2提供了与REST一起使用的HTTP动词的更大定义。但是，我看到许多关于它的实用程序的文章来回摆动。 因此，我应该使用WADL来允许外部代码生成器快速为我的Web应用程序构建客户端，还是期望有更好的标准？

27 web-applications  rest  standards 

至少在SQL中，数据库表名称应为单数，这是一个非常明确的约定。SELECT * FROM user;请参阅此问题和讨论。 RESTful API资源名称应为复数形式，这也是一个相当明确的约定。GET /users/123并POST /users看到这个。 在最简单的数据库支持的API中，URL中的资源名称将是表，URL中的数据元素和请求/响应主体将直接映射到DB中的列。从概念上讲，我认为通过此理论API对数据进行操作与直接通过SQL对数据进行操作之间没有区别。因此，user和之间的命名约定差异users对我来说没有意义。 从概念上来说，当REST API和SQL做相同的事情时，如何证明多元化的合理性？

27 rest  api  sql  conventions  naming-standards 

我们有一个asp.net MVC Web服务框架，用于为人们获取请求提供xml / json，但正在努力找出验证用户的最佳方法（对于使用javascript或OO语言进行编码的用户而言，快速，简便，琐碎）。这并不是说我们的数据是敏感数据或任何东西，我们只是希望用户注册，以便我们可以使用其电子邮件地址来通知他们更改和跟踪使用情况。 在我们先前的尝试中，我们在URI中使用了用户名，并且只需确保存在用户名并使用使用率来递增db表。这是超级基础，但我们会注意到人们使用demo作为用户名等，因此我们需要使其更加复杂。 有哪些身份验证技术可用？主要参与者使用/做什么。

26 security  api  web  services  rest 

我正在考虑将整体式REST API移至微服务体系结构，并且对数据存储有些困惑。如我所见，微服务的一些好处是： 水平可伸缩-我可以运行微服务的多个冗余副本以应对负载和/或服务器故障。 松散耦合-我可以更改微服务的内部实现而不必更改其他服务，并且我可以独立部署和更改它们等。 我的问题是数据存储。在我看来，有几种选择： 所有微服务共享一个数据库服务-这似乎完全消除了松耦合的任何好处。 每个微服务上的本地安装的数据库实例-我看不到横向扩展此方法的方法，因此我认为这不是一个选择。 每个微服务都有自己的数据库服务-这似乎是最有前途的，因为它保留了松散耦合和水平扩展的优势（使用冗余数据库副本和/或跨多个分片） 在我看来，第三种选择似乎是唯一的选择，但是对我来说，这似乎是难以置信的沉重负担，并且是一种过度设计的解决方案。如果我理解正确，那么对于具有4-5个微服务的简单应用程序，我将必须运行16-20台服务器-每个微服务两个实际的微服务实例（以防服务器故障，并且在不停机的情况下进行部署），以及每个微服务有两个数据库服务实例（如果发生服务器故障等）。 坦率地说，这似乎有些荒谬。要记住，一个现实的项目可能会提供4-5个以上的服务，而16-20个服务器运行一个简单的API，该不该？我是否缺少一些基本的概念来解释这一点？ 回答时可能会有所帮助的一些事情： 我是该项目的唯一开发人员，并将在可预见的将来。 我正在使用Node.js和MongoDB，但是我对与语言无关的答案很感兴趣-一个答案甚至可能是我使用了错误的技术！

25 architecture  rest  api-design  microservices 

我正在移动端上开发一个新的iOS应用程序项目。正在进行一些体系结构更改，事实证明，我们将不得不依赖自定义构建的私有API，该API将由我们正在构建的应用程序以及网站等其他客户端使用。 正在设计的API遵循映射到HTTP动词的以资源为中心的URI和CRUD操作的Rest样式。像： GET www.example.com/books DELETE www.example.com/books/482094 POST www.example.com/users/6793 问题在于，这种风格通常导致移动客户端需要执行许多请求来加载单个应用程序屏幕或管理单个用户UI操作。这将导致应用程序处于加载模式8秒钟，直到拥有所需的一切为止。缓慢且无响应的应用程序。 移动客户端在连接方面有严重的限制，因此理想情况下，我们应遵循以下规则： 1个屏幕== 1个API调用 1个保存== 1个API调用。 在许多情况下，这会使您与REST设计原则发生冲突，例如： 假设您的应用离线了一天，您需要与后端数据库的四个表进行同步，并且您需要像 www.example.com/sync_everything?since=2015-07-24 可以说有一个屏幕，用户可以在其中编辑许多对象，例如在待办事项列表中勾选任务。应该有一种方法可以在一个批处理API调用中编辑所有这些任务记录，而不是每次编辑都可以一个API调用。 假设有一个混合了来自ORDER，SALESMEN和PRODUCT数据库表的信息的屏幕，我应该一次调用而不是三个调用来获取该数据。 这样做的风险是，我们最终可能会获得最宁静的API，以及最无用的无响应移动应用程序。 问题是我只是那里的新承包商，我需要的是可以帮助我阐明这些要点的东西，一些受到尊敬的消息来源的文章等等。主要参与者在针对其移动客户端的REST风格上妥协（例如：通过使用复合聚合API端点）。 或针对此一般问题的任何解决方案。谢谢！

25 rest  api  ios  mobile