Questions tagged «rest»

这是第一个RESTful Web服务，我担心安全性问题。通过HTTP标头传输访问令牌是否安全？例如： POST /v1/i/resource HTTP/1.1 Content-Type: application/x-www-form-urlencoded Api-key: 5cac3297f0d9f46e1gh3k83881ba0980215cd71e Access_token: 080ab6bd49b138594ac9647dc929122adfb983c8 parameter1=foo&parameter2=bar 连接已建立SSL。另外，需要定义什么作为scope每个属性access token

11 api  rest  http  headers  http-request 

只需在REST API规则手册中阅读以下内容：不得使用GET和POST来传送其他请求方法。 隧道是指对HTTP的任何滥用，它们会掩盖或错误表示消息的意图并破坏协议的透明性。REST API不得通过滥用HTTP的请求方法来折衷其设计，以适应具有有限HTTP词汇量的客户端。始终正确使用本节中的规则指定的HTTP方法。[我的重点] 但是随后，由于只了解和，许多框架使用隧道来通过HTML表单公开REST接口。我最近的示例是一个for flask（由框架的作者提交）：http : //flask.pocoo.org/snippets/38/。<form>GETPOSTMethodRewriteMiddleware 在Web框架中没有黑客或附加组件的情况下，有什么方法可以遵守“规则”？

11 api  rest  web-framework  http 

我有许多构成Web应用程序的Web服务。客户端可以通过REST API调用访问这些服务。 这些服务应该能够彼此直接对话吗？如果是这样，这是否会使他们成为夫妇，这违背了微服务的概念？ 客户端是否应该一个接一个地直接调用它们以获取在客户端上加载网页所需的数据？ 还是我应该在服务之上设置另一层来处理来自客户端的请求，获取该请求的数据，然后将其发送回客户端？

10 architecture  rest  microservices 

我们正在为我们的项目构建微服务架构，其中大多数前端Symfony应用程序与后端RESTful API进行交互。 问题在于，这种方法打破了严重依赖带有数据库的Doctrine的Symfony实体管理。Symfony通常使用Doctrine处理实体，从而使大部分工作自动化，而当我们必须从API访问外部数据时，就很难轻松地重现这一点。 例如，对于客户实体： 使用Doctrine，我们只需要定义Client类，现在就可以轻松地创建，更新和检索客户 使用REST API方法，可以通过API访问客户端，但是我们还有很多工作来定义如何创建（POST），更新（PUT），检索（GET）客户端等。 需要注意的是，客户端被多个应用程序使用，不仅是前端应用程序，还有专用的API。 我们是否应该使用类似于实体的方法来创建类，从而隐藏API调用的复杂性，在本地导入所有API数据并通过Doctrine或其他方式访问它们？

10 php  rest  api  microservices  symfony 

在使用HATEOAS约束构建REST服务时，通过链接宣传存在的资源非常容易。您GET以我的网站的根目录为基础，然后我以列出所有第一层资源的根目录文档进行响应： { users: { href: "/users" } questions { href: "/questions" } } 了解如何读取这些href值的客户端可以对这些值执行GET请求，并发现应用程序中所有可用的当前资源。 这对于基本的查找方案非常有效，但不能指示资源是否可查询。例如，执行以下操作可能是合理的： GET /users?surname=Smith 是否有任何格式可以用足够的信息来表达此查询功能，以使客户端无需事先了解资源就可以形成连贯的查询？ 另外，有什么方法可以表示允许客户端POST对具有预期位置的给定位置执行操作。例如，可以期望客户执行以下操作来创建新的问题资源： POST /questions { title: "Are there strategies for discovering REST services using HATEOAS?", body: "When building a REST service with the HATEOAS constraint, it's very..." } 当使用HTML作为人类消费的格式时，我们可以通过使用表格和书面提示来表达很多这种形式，以使人们能够发现他们被允许对服务执行的操作。 是否有能够为客户提供类似功能的格式？

10 design  rest  hateoas 

我有三个关于REST API设计的问题，希望有人能对此有所启发。我已经不懈地搜索了多个小时，但没有在任何地方找到我的问题的答案（也许我只是不知道要搜索什么？）。 问题1 我的第一个问题与动作/ RPC有关。我已经开发了REST API已有一段时间了，我习惯于从集合和资源的角度思考事物。但是，我遇到了一些似乎没有适用该范式的案例，并且我想知道是否有一种方法可以将其与REST范式进行协调。 具体来说，我遇到一种情况，即修改资源会导致生成电子邮件。但是，稍后用户可以特别指出他们想重新发送之前发送的电子邮件。重新发送电子邮件时，不会修改任何资源。状态没有改变。这只是一个需要发生的动作。该操作与特定的资源类型相关。 将某种动作调用与资源URI（例如/collection/123?action=resendEmail）混合使用是否合适？指定动作并将资源ID传递给它（例如/collection/resendEmail?id=123）会更好吗？这是错误的做法吗？传统上（至少使用HTTP）执行的动作是请求方法（GET，POST，PUT，DELETE），但实际上不允许使用资源进行自定义动作。 问题2 我使用URL的querystring部分来过滤查询集合时返回的资源集（例如/collection?someField=someval）。然后，在我的API控制器中，我确定将与该字段和值进行哪种比较。我发现这真的行不通。我需要一种允许API用户指定他们想要执行的比较类型的方法。 到目前为止，我想到的最好的主意是允许API用户将其指定为字段名称的附录（例如/collection?someField:gte=someval-表示它应返回someField大于或等于（> =）someval的资源。这是一个好主意吗？是一个坏主意？如果是，为什么？有没有更好的方法可以让用户指定要对给定字段和值执行的比较类型？ 问题3 我经常看到URI的那样子像/person/123/dogs拿到person小号dogs。我通常避免这样的事情，因为最后我发现通过创建类似的URI，您实际上只是在访问dogs按特定personID 过滤的集合。等同于/dogs?person=123。真的有充分的理由使REST URI的深度超过两个级别（/collection/resource_id）吗？

10 api  rest 

最近完成了一个处理信用卡处理的项目。我面临的困难之一是处理通知消息的延迟/可能失败。最复杂的示例是： 发送付款请求的外部系统 我的系统将该请求转换为对支付网关的请求 将用户发送到网关 等待用户执行付款 用户返回我的系统，但是一直被保留，直到系统收到成功/失败通知 根据故障将用户发送回外部系统 更加困难的事实是，一旦发送通知失败，网关将尝试每15分钟发送通知数小时。 我使用未决事务的数据库记录解决了它，然后从返回中加上成功的延迟侦听器（用于通知和事务处理）来检测返回的成功和失败... 相当困难！ 但是，这一定已经解决了无数次，所以最佳实践是什么？ 我看到我的未来将是编写所有这些系统之间的处理程序，并管理时间延迟和可能的网络故障，因此我希望遵循最佳实践。 书籍/文章推荐会很棒。 提前致谢！

10 web-services  rest  distributed-computing 

在编写单元测试时，通常使用固定装置：可测试的数据很少，因此我们可以说：1.让所有客户都应该包括Willy Wonka。2.删除客户端3，现在获取客户端不应再包括Willy Wonka。 单元测试很好。使用设置/拆卸来重新加载固定装置或回滚事务。因此，测试可以在事务内部完成创建，更新和删除操作。新的临时数据仅持续测试时间，然后被重置。 但是，当我们将REST服务器与REST客户端分离时该怎么办？ 我们要确保REST客户端不仅正确读取，而且正确创建，更新和删除。 对于如何针对远程测试REST服务器执行此操作，我找不到任何示例或建议。 假设我有一个仅测试灯具的测试REST服务器。HTTP的整个无状态性质意味着很难发送“ BEGIN TRANSACTION”和“ ROLLBACK TRANSACTION”或“ RELOAD FIXTURES”类型的消息，对吗？ 我不能成为第一个这样做的人，所以我觉得我需要以不同的方式来思考这个问题。 有什么建议么？

10 unit-testing  api  rest 

创建REST服务时，我基本上已经注视着要执行以下操作： 要求HTML 服务返回所需的网页，但没有请求的“资源”，例如。数据 网页包含向同一服务发出AJAX请求的JavaScript（不同的内容类型） 服务然后返回实际数据（JSON），然后页面将其显示 一方面，它似乎效率低下（2个请求），但后来我用了它，“性能无关紧要”，这意味着内部应用程序和网站的低流量运行非常简单且加载速度很快。 我之所以这样做，是因为该网页几乎可以是纯HTML + JavaScript的，几乎不需要服务器端的东西，尤其是不需要循环，就可以创建表和类似的东西（与之相比，我觉得这很丑陋）诸如slickgrid之类的东西），例如数据和视图的分离。 现在，在我开始使用它之前，这是个好主意还是应该停止这样做？

10 web-services  rest  anti-patterns 

我一直在想，而不是像这样更传统的布局： api/Products GET // gets product(s) by id PUT // updates product(s) by id DELETE // deletes (product(s) by id POST // creates product(s) 具有单数和复数会更有用，例如： api/Product GET // gets a product by id PUT // updates a product by id DELETE // deletes a product by id POST // creates …

10 rest 

我有以下端点： a/{id}/b 并希望创建一个b带有发送POST请求的请求。如果a给定{id}没有找到我应该响应404 NOT_FOUND或可能有409 CONFLICT？ 它是处理简单的a/{id}，窍门是这里使用了一个子资源。

10 rest  api  api-design  http-request 

我正在创建REST API，目前，我遇到以下问题： Foo是第一资源。可以通过/foo/URI 应用CRUD操作。 Bar是第二资源。可以通过/bar/URI 应用CRUD操作。 每个Foo都与零或一相关联Bar。之所以不将其Bar视为的子资源，Foo是因为Bar可以在Foo多个s 之间共享同一实例。因此，我认为最好通过独立的URI而不是通过URI访问它/foo/[id]/bar。 我的问题是，在很多情况下，请求Foo实例的客户端也对关联的Bar实例感兴趣。当前，这意味着他们必须执行两个查询而不是一个。我想介绍一种允许通过单个查询获取两个对象的方法，但是我不知道如何为此建模。到目前为止，我想出了什么： 我可以引入类似于以下内容的查询参数：/foo/[id]?include_bar=true。这种方法的问题在于，响应的资源表示形式（例如JSON结构）将需要看起来不同（例如，容器{ foo: ..., bar: ... }而不是仅序列化的容器Foo），这会使Foo资源端点“异构”。我不认为这是件好事。查询时/foo，无论查询参数如何，客户端都应始终获得相同的资源表示形式（结构）。 另一个想法是引入一个新的只读端点，例如/fooandbar/[foo-id]。在这种情况下，返回像这样的表示形式没有问题{ foo: ..., bar: ... }，因为那样的话，它只是fooandbar资源的“正式”表示形式。但是，我不知道这样的辅助端点是否真的是RESTful的（这就是为什么我在问题的标题中写了“ can”的原因。当然，从技术上讲这是可能的，但是我不知道这是一个好主意）。 你怎么看？还有其他可能性吗？

10 rest  web-api  resources 

在实施我们的API时，出现了日期时间和时区的问题。 所有日期均已标准化为数据库中的UTC。当前，在非API应用程序中，所有日期时间都是根据用户的偏好设置先转换后才呈现。 现在，对A​​PI提出了同样的问题：API是否应该能够基于请求语义返回适合时区的datetime？ 例如GET /posts?timezone=America/Sao_Paulo？ 还是应该在正在访问API的任何客户端上完成此操作？ 更新：因为它出现了几次：当前返回带有时区的时间戳（尽管始终为TZ offset +00:00）。格式是流行的8601：2015-10-29T23:00:49+00:00

10 rest  api  time 

我正在构建一个REST api，其中使用客户端证书对客户端进行身份验证。在这种情况下，客户端不是单个用户，而是某种表示层。使用自定义方法对用户进行身份验证，表示层有责任确保此方法正确完成（注意：我知道这不是正确的方法，但api不公开）。 我想传递每个请求的用户名（而不是密码），但是我不确定在哪里执行此操作。使用Authorization标头是个好主意吗？

10 rest  authentication  headers 

像这样： Campaign: type: object properties: id: type: string description: "A GUID identifier" referenceId: type: string description: "A consumers identifier they have used to map their own systems logic to this object." name: type: string description: "'Great Campaign 2017' as an example" 我担心referenceId。 系统域是一个平台，该平台通过数据导出和各种格式（xml，excel）的导入以多种方式与第三方集成。它已经足够成熟，可以允许第三方通过API与我们的系统集成，而该API的设计正是引发这一问题的原因。 我们有一个名为Campaign的对象，该对象的ID可用于识别和检索资源。我们API的消费者可能在自己的域内拥有自己的参考代码，以作为他们认为是广告系列的参考代码。 我们系统中还有其他带有第三方参考字段的对象，这是我们现有消费者所期望的。但是我担心这给我们增加了映射的负担，我们不知道这个referenceId是什么（数字，文本，json？），并且为新使用者增加了另一个令人困惑的属性。 在API的公共对象定义中允许第三方引用ID字段被视为不良做法或不良设计？

9 rest  api  domain-driven-design  api-design  single-responsibility