Questions tagged «rest»

创建RESTful API时，应该在相同的URL上使用HTTP动词（如果可能），还是在每个操作中创建特定的URL？ 例如： GET /items # Read all items GET /items/:id # Read one item POST /items # Create a new item PUT /items/:id # Update one item DELETE /items/:id # Delete one item 或使用特定的网址，例如： GET /items # Read all items GET /item/:id # Read one item POST /items/new # …

25 rest  api-design  web-api 

在我当前的项目中，我负责服务的实现，该服务涉及使用新创建的RESTful API，这些文档记录为仅支持JSON。 客户端始终使用“ application / json”的接受标头和“ application / json”的内容类型发出请求。但是，某些端点会发送带有HTML内容类型的响应，甚至是HTML正文。对我来说，这显然是错误的方法，永远无法辩解。 在整个项目中，相同的做法已应用于两个不同的供应商和两个不同的服务。我发现自己必须证明为什么需要更改服务。供应商表示，客户端应对此进行处理，甚至我选择的REST库也受到了质疑（RestEasy），因为默认情况下它不应对此问题。 这是一个主要的挫败点。我找不到很多引用来支持我的论点，我认为这是因为要点很明显，所以没有意义。 问题是，我缺少什么吗？我对此很腐吗？在这种情况下，可以使用不具有application / json内容类型的JSON API吗？参考将不胜感激。您如何从商业角度解决这种情况？

25 rest  api-design  json  bad-code 

对于我的工作，我们有一个不错的RESTful Web服务，我们已经建立了该服务，用于驱动我们拥有的几个网站。基本上，Web服务使您可以创建和使用支持凭单，并且网站负责前端。任何网络服务请求都使用auth标头，我们使用该标头来验证用户及其每次呼叫的密码。 今年，我们正在寻求扩展登录选项，以便网站上的用户可以通过Google，Twitter和Facebook（可能还有其他）登录。但是，我在弄清楚如何设计该结构方面很麻烦，因此Web服务可以使用第三方身份验证提供程序来确保用户就是他们所说的。是否有最佳实践来做到这一点？ 当前，我们正在考虑让网站处理用户本身的身份验证，然后使用一个新的setSessionId调用来将其当前会话注册到Webservice后端。对Web服务的每个其他请求都将传递该sessionId并将对其进行验证。这些看起来还可以，但是我的内心深处感到我没有考虑透彻，所有浏览和阅读oauth和openid规范的论坛都让我更加困惑。有什么技巧可以解决这个问题吗？

25 web-services  rest  authentication  oauth  openid 

尝试为具有变更前瞻性的外部应用程序设计API并非易事，但预先考虑可以使以后的生活变得更轻松。我正在尝试建立一个方案，以支持将来的更改，同时通过保留先前的版本处理程序来保持向后兼容。 本文的主要关注点是对于给定产品/公司，所有定义的端点应遵循哪种模式。 基本方案 鉴于基本URL模板https://rest.product.com/我设计，所有的服务都位于下/api沿/auth和其他基于非休息终点如/doc。因此，我可以如下建立基本端点： https://rest.product.com/api/... https://rest.product.com/auth/login https://rest.product.com/auth/logout https://rest.product.com/doc/... 服务端点 现在是端点本身。关注度POST，GET，DELETE不是本文的主要目的，是对这些行为本身的关注。 端点可以分为名称空间和动作。每个动作还必须以支持返回类型或所需参数的基本更改的方式显示自己。 在注册用户可以发送消息的假设聊天服务中，我们可能具有以下端点： https://rest.product.com/api/messages/list/{user} https://rest.product.com/api/messages/send 现在添加版本支持，以支持将来可能会中断的API更改。之后我们既可以添加版本签名/api/或之后/messages/。给定send端点，我们可以为v1提供以下内容。 https://rest.product.com/api/v1/messages/send https://rest.product.com/api/messages/v1/send 所以我的第一个问题是，版本标识符的推荐位置是什么？ 管理控制器代码 因此，现在我们已经确定需要支持以前的版本，因此需要以某种方式处理可能随着时间而弃用的每个新版本的代码。假设我们正在用Java编写端点，则可以通过包来管理它。 package com.product.messages.v1; public interface MessageController { void send(); Message[] list(); } 这样做的好处是，所有代码已通过命名空间分隔开，其中的任何重大更改都将意味着服务端点的新副本。这样做的不利之处在于，需要复制所有代码，并且希望对每个副本都应用/测试希望应用于新版本和先前版本的错误修正。 另一种方法是为每个端点创建处理程序。 package com.product.messages; public class MessageServiceImpl { public void send(String version) { getMessageSender(version).send(); } // Assume we have …

25 design  design-patterns  web-services  rest  services 

已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗？更新问题，以便通过编辑此帖子以事实和引用的形式回答。 4年前关闭。 您如何称呼基于HTTP的API，该API使用URI命名资源，并使用HTTP动词（PUT，POST，DELETE，GET ...）来操纵这些资源？ 根据Roy Fielding的抱怨，它不是REST，因为没有超媒体。 在我的团队内部，每个人都将其称为“ REST API”。我称其为“类似REST”，但它不是描述性的，其含义还很模糊。我对此非常困惑，因为关于REST存在巨大分歧。我不想参加火焰大战，只是使用正确的用语。

24 terminology  rest  api  http 

我正在为一个项目设计REST API，在该项目中，用户始终处于多个“计划”之一中-每个计划都定义了一些资源限制，例如帐户可能拥有的最大用户数或他们可以上传的最大数据数。一旦达到这些限制之一，用户就可以升级他们的计划（基本上是付费）以获得更多资源。 我想返回一个特殊的状态代码，该状态代码表示由于帐户资源限制而无法执行操作的情况，因此升级计划将解决此问题-例如，如果用户使用了其存储容量的100％，并尝试上传其他文件，他们将收到此回复。 候选人是恕我直言： 403 Forbidden -但是，我想区分这种情况和其他情况，即用户只是缺乏执行此操作的权限。 401 Unauthorized -不是一个好主意，我们正在使用它来解决与身份验证相关的问题。 402 Payment Required -有道理，但我担心使用非标准但保留的状态码 甚至不太标准的423 Locked东西，例如将来我们不太可能将其用于其他任何东西 另一种选择是使用一些非常标准的东西，例如，403但在响应主体中指出错误的细节。 我想知道您相信哪种方法（a）从长远来看效果最好，并且（b）将更好地坚持RESTful原则。

24 rest  api-design  http 

我们有一个资源数据库，无论是产品，博客文章还是其他资源。我们需要为公共网站设计一个URL方案来解决它们。 这是绑定数据库ID的两个示例： https://www.youtube.com/watch?v=7FPS6llqhXw http://www.amazon.co.uk/gp/product/B000NHOMSQ 这是一个友好的示例： http://en.wikipedia.org/wiki/LED_circuit （瞥见我在那里的浏览生活） 我喜欢友好的URL，因为当您将鼠标悬停在电子邮件或文档中或在电子邮件或文档中看到URL时，您会知道URL末尾的含义。SEO更好，或者曾经是。 重命名文档或产品时会发生什么？是因为它已更改（Wiki可能不会更改，但我们的资源可能会更改）还是由于输入错误，对吗？我们的资源非常技术性，冗长且容易出错。 另外，我们有一个数据库ID，它是一个数字。让我们来看一个使用假装租赁商店的视频地址的想法： http://vidsyeah.com/video/sliding-doors/287171 该ID很明显，并用于数据库查找中。精细。 滑动门不是唯一的，只是从视频标题生成的，可以在GET上进行验证，因此，如果输入了滑动门，但与文档287171中的内容不匹配，则会响应404。 或者，也许它可以忽略不计，如果有人关心的话，它允许人类将他们喜欢的东西粘在里面。因此，该URL也将起作用： http://vidsyeah.com/video/anything-at_all/287171 如前所述，验证友好部分的问题是重命名或拼写错误的问题。如果名称更改，并且确实发生在我们的域中，我们不想破坏那里的URL，那么我们应该： 只是不验证友好部分。 验证，但在数据库记录中添加友好零件的“历史记录”，以便任何以前的友好ID仍然有效！ 欢迎您的想法和想法。 路加

24 web-applications  rest  web  websites  http 

在本文中，作者声称 有时，需要公开API中固有的非RESTful操作。 然后 如果一个API有太多的动作，则表明它是使用RPC观点设计的，而不是使用RESTful原理设计的，或者所讨论的API自然更适合RPC类型模型。 这也反映了我在其他地方阅读和听到的内容。 但是，我觉得这很令人困惑，我希望对此事有更好的了解。 示例I：通过REST接口关闭VM 我认为，有两种根本不同的方法来对虚拟机关闭建模。每种方式可能会有一些变化，但现在让我们集中讨论最基本的差异。 1.修补资源的状态属性 PATCH /api/virtualmachines/42 Content-Type:application/json { "state": "shutting down" } （或者，PUT在子资源上/api/virtualmachines/42/state。） VM将在后台关闭，并且在稍后的某个时间点（取决于关闭的成功与否）将成功，否则状态可能不会通过“关闭电源”在内部进行更新。 2.在资源的actions属性上进行PUT或POST PUT /api/virtualmachines/42/actions Content-Type:application/json { "type": "shutdown" } 结果与第一个示例完全相同。该状态将立即更新为“关闭”，并可能最终更新为“关闭电源”。 两种设计都是RESTful的吗？ 哪个设计更好？ 示例II：CQRS 如果我们有一个CQRS域，其中包含许多这样的“操作”（又称命令），它们可能潜在地导致多个聚合的更新，或者无法映射到具体资源和子资源上的CRUD操作？ 我们是否应该在可能的情况下尝试建模尽可能多的命令，具体取决于在具体资源上创建或更新的具体资源（遵循示例I的第一种方法），其余部分使用“动作端点”？ 还是应该将所有命令映射到动作端点（如示例I的第二种方法）？ 我们应该在哪里划界线？设计何时变得不那么RESTful？ CQRS模型是否更适合RPC之类的API？ 据我了解，根据上面引用的文字。 从我的许多问题中可以看出，我对该主题有些困惑。您能帮我更好地了解它吗？

24 rest  domain-driven-design  api-design  cqrs 

我试图了解Odata的意义以及何时才有意义。现在，我的工作方式是使用ASP.NET和MVC / WebApi控制器将对象序列化/反序列化为JSON，并让javascript对其进行处理。 据我所知，OData的优点是能够直接从URL查询...但是由于我正在编写客户端和服务器代码，因此不需要这样做。 有人会用JavaScript解析ODaya查询的结果吗？ 也许OData更多地是为所有客户端提供通用终结点，以便从JSON不提供的查询中获取详细信息？因此，如果我是数据提供者，那么我想那是odata的作用吗？ 帮助我了解REST / JSON / ODATA的目的和用途。

23 javascript  rest  json 

假设我有一家公司对互联网上最可爱的猫进行排名。 我提供的资源/cats/可为用户提供最新，最可爱的可爱猫咪。 如果他们根本没有付款或没有注册，用户可以只获得排名前三的猫。如果付款的话，排名前10的猫是337美元，如果登录的话，排名前100位的猫是1。 简而言之，的消费者/cats/会根据其“用户排名”获得不同数量的猫。我在消费端确实有一个用户标识符，但是在消费端没有明确表示用户级别。我想通知用户他们可以在提出请求时升级其订阅。也就是说，我需要区分3只猫，因为我只提供3只猫和3只猫，因为这是用户级别所允许的。 区分由于消费者没有足够的特权而限制资源和因为消费者具有足够的特权而对其进行区分的最佳实践是什么？ 客户如何知道他们是否可以提高排名？也就是说，他们只有有限的资源，因为他们没有权限。最佳做法是什么？ 注意，这是实际情况的粗略简化。另外，为了澄清-感谢阅读。 更新： 我们考虑了以下选项： 仅在客户端上存储一次用户权限对象，仅在执行帐户登录或升级时对其进行查询。 null在JSON中传递值表示存在，但实际上什么也没有转移。因此，对于有3只猫的用户来说，这可能是10只猫["Garfield","Sylvester","Puss in Boots",null*7] 传递资源许可对 {cats:["Whiskers","Fluffy","Socks"],authCount:3} 我想在第一时间做到这一点，以可能的最佳方式运送最可爱的猫，我们也希望

23 rest  http  url  http-response 

假设系统中有一个带资源的Web应用程序，以及另一个具有类似资源的远程应用程序的引用，那么您如何表示双向同步操作，该操作将“本地”资源与“远程”资源同步？ 例： 我有一个代表待办事项清单的API。 GET / POST / PUT / DELETE / todos /等 该API可以引用远程TODO服务。 GET / POST / PUT / DELETE / todo_services /等 我可以通过我的API作为代理通过远程服务来处理待办事项 GET / POST / PUT / DELETE / todo_services / abc123 /等 我希望能够在本地待办事项集和远程待办事项集之间进行双向同步。 以一种rpc的方式， POST / todo_services / abc123 / sync / 但是，在“动词很糟糕”的想法中，是否有更好的方法来表示此动作？

23 api  rest  api-design  synchronization 

我正在设计一个实用的REST API，并且对如何最好地将现有实体添加到集合中有些困惑。我的域模型包括一个具有站点集合的项目。这是一个严格的多对多关系，我无需创建一个显式建模该关系的实体（即ProjectSite）。 我的API将允许使用者将现有站点添加到项目中。我挂断电话的地方是，我真正需要的唯一数据是ProjectId和SiteId。我最初的想法是： 1. POST myapi/projects/{projectId}/sites/{siteId} 但是我也想过 2. POST myapi/projects/{projectId}/sites 与作为JSON内容发送的Site实体。 选项1简单易用，但感觉不太正确，而且我还有其他关系无法遵循此模式，因此它增加了我的API的不一致性。 选项2感觉更好，但引起两个问题： 如果发布了新网站（SiteId = 0），我应该创建一个网站还是引发异常？ 因为我只需要ProjectId和SiteId来创建关系，所以该站点可能发布的其他属性数据有误或缺失。 第三种选择是提供一个仅用于创建和删除关系的简单端点。该端点将期望仅包含ProjectId和SiteId的JSON有效负载。 你怎么看？

23 rest  api-design 

我的公司目前正在努力采用微服务架构，但是在此过程中我们遇到了一些麻烦（令人震惊）。我们面临的主要争论点之一是如何在我们的不同服务之间传递大量数据。 作为背景知识，我们有一个文档存储，可作为我们可能需要在公司范围内处理的任何文档的存储库。与所述商店的交互是通过服务完成的，该服务为客户提供了唯一的ID和流文档的位置。以后可以通过使用提供的ID进行查找来访问文档的位置。 问题是-对于我们所有的微服务而言，是否为了与文档进行交互而接受此唯一ID作为其API的一部分有意义吗？在我看来，这本质上是错误的-服务不再是独立的，而是依赖于文档存储的服务。尽管我确实承认这可能会简化API设计，甚至可能会带来一些性能提升，但所产生的耦合效果远不止于此。 有谁知道彩虹独角兽（Netflix，亚马逊，谷歌等）如何处理服务之间的大文件/数据交换？

22 design  rest  xml  microservices 

我正在创建新的业务Web应用程序，并且想要实现： 使用各自领域的最佳技术。我想要具有可靠ORM的可靠后端框架。我想要最先进的SPA（单页应用程序）框架，并为前端应用程序使用最新的HTML和Javascript功能 公开后端实体和业务服务以供不同类型的应用程序使用，例如，Web应用程序，移动（Android）以及可能的其他类型（智能设备等） 因此，为了满足这两个要求，我倾向于将我的应用程序完全隔离在后端和前端应用程序中，并使用REST API（JSON）来组织它们之间的通信。这是合理的方法吗？ 这种分离并不是显而易见的设计解决方案，因为许多Web应用程序技术都集成了视图层，其中服务器端应用程序或多或少地控制视图的生成并部分处理视图的响应（例如，带有视图层的SpringMVC，带有视图的PHP Yii Java JSF / Facelets层将其组件的状态完全保存在服务器上）。因此-周围有许多技术提出了更强的耦合性，并有望缩短开发时间和提供更标准的路径。所以-在开始以未广泛使用的方式使用技术时，我必须谨慎。 据我了解，完全分离的SPA前端通常是由使用第三方API引起的。但是，当后端和前端都由一家公司开发时，这种去耦声音设计是否有效？ 我目前选择的技术是Java / Spring后端和Angular2 / Web组件/聚合物前端-如果允许我这么说的话。但这与这个问题无关，因为这个问题是关于一般设计而不是具体技术的选择？

21 design  rest  api  front-end  backend 

我在一个产品组中有一个产品集合，例如： product-groups/123/products 如果我需要添加到集合中，可以通过PUT 只传递某些产品吗？ 如果我需要从集合中删除某些产品，可以通过DELETE 传递过滤器数据（ID数组）吗？ 秉承ReST精神实现功能的最佳方法是什么？ 编辑：项目是指向单独实体（基本上是产品ID）的链接。

21 rest  collections