软件工程 rest

2

我们开发基于社交的移动应用程序。每个应用程序都使用RESTful API Web服务。实施登录时，我通常将用户名和密码存储在设备上的某个位置。然后，我发送给他们，作为回应，我可以访问我的个人资料。但是我也知道还有另一种方法。一个人用一种特定的算法生成令牌，然后发送令牌而不是用户名和密码来获得访问权限。我应该如何实施？除登录外，我是否应将此令牌与其他所有请求一起发送？

21 mobile rest login

7

作为REST API客户端的Web应用程序：如何处理资源标识符

当我尝试实施REST时，与REST相关的几个概念就在我的脑海中。我有一个包含业务逻辑的REST-ful后端API系统，以及一个提供UI的Web应用程序。从有关REST的各种资源（特别是REST在实践中：超媒体和系统体系结构）中，我知道我不应该公开实体的原始标识符，而应该返回带有的超链接rel="self"。考虑这个例子。REST api具有返回一个人的资源： <Person> <Links> <Link rel="self" href="http://my.rest.api/api/person/1234"/> </Links> <Pets> <Link rel="pet" href="http://my.rest.api/api/pet/678"/> </Pets> </Person> Web应用程序出现问题。假设它返回的页面包含浏览器的超链接： <body class="person"> <p> <a href="http://my.web.app/pet/???????" /> </p> </body> 我应该在href属性中添加什么？当用户打开目标页面时，如何将API实体URL保留在Web应用程序中以便能够获取该实体？要求似乎有冲突：超链接href应指向Web应用程序，因为它是承载UI的系统本href应该有实体的一些ID，因为Web应用程序必须能够在目标页打开时，解决实体提到的书说，Web应用程序不应解析/构造REST URL，因为它不是基于REST的。 URI对消费者应该是不透明的。只有URI的颁发者知道如何解释它并将其映射到资源。因此，我不能仅仅1234取自API响应URL，因为作为RESTful客户端，我应该将其视为http://my.rest.api/api/AGRIDd~ryPQZ^$RjEL0j。另一方面，我必须提供一些URL，这些URL可以引到我的Web应用程序，并且足以使该应用程序以某种方式还原API的原始URL，并使用该URL来访问API资源。最简单的方法可能只是使用资源的API URL作为它们的字符串标识符。但是网页网址http://my.web.app/person/http%3A%2F%2Fmy.rest.api%2Fapi%2Fperson%2F1234很丑陋。对于台式机应用程序或单页javascript应用程序而言，这似乎非常容易。由于它们持续存在，因此它们可以将URL与服务对象一起保留在内存中，以延长应用程序的生命周期，并在必要时使用它们。使用Web应用程序，我可以想象几种方法，但是所有方法似乎都很奇怪：替换API URL中的主机，并仅保留结果。巨大的缺点是，它需要Web应用程序处理API生成的任何URL，这意味着怪异的耦合。而且，它不再是RESTful的，因为我的Web应用程序开始解释URL。公开REST API中的原始ID及其链接，使用它们来构建Web App的URL，然后使用Web App Server上的ID在API中找到所需的资源。这样比较好，但是会影响Web应用程序服务器的性能，因为Web应用程序必须通过REST服务导航来发出一系列形式的获取ID请求的链接，以处理来自浏览器的任何请求。对于有些嵌套的资源，这可能会很昂贵。 self将api返回的所有URL 存储在Web应用服务器上的持久（DB？）映射中。为它们生成一些ID，使用这些ID构建Web应用程序页面URL并获取REST服务资源的URL。也就是说，我http://my.rest.api/pet/678用一个新的密钥将URL 保留在某处3，然后将网页URL生成为http://my.web.app/pet/3。这看起来像某种HTTP Cache实现。我不知道为什么，但是对我来说似乎很奇怪。还是所有这些都意味着RESTful API不能用作Web应用程序的后端？

21 web-applications rest

4

REST与RESTful与“普通” Web服务-是否相同？

我已经阅读了关于REST和/或RESTful应用程序的一些定义和讨论，但是我仍然不了解它的真正含义。我通常使用的应用程序要么通过GET获取数据，要么通过POST发送数据到某个Web服务（通常是PHP脚本），然后从数据库获取数据或将数据写入数据库。现在，这是RESTful应用程序吗？如果没有，那么什么是RESTful应用程序？RESTful概念和我到目前为止合作过的概念有什么区别？请举例说明。另外，有人在谈论REST，有人在谈论RESTful应用程序。我发现REST术语是指理论概念，而当我们谈论特定的应用程序时则使用RESTful。这是正确的做法还是REST和RESTful应用之间存在真正的区别？

21 java php web-services mobile rest

5

适用于公共REST API的OAuth2 ROPC与基本身份验证？

我在这里感兴趣的特定用例是针对可公开使用的服务器端点（例如，公共REST API）对REST客户端进行身份验证。这里最简单的解决方案是Basic Auth。但是我经常听到OAuth2在几乎所有情况下都被视为一种出色的身份验证解决方案。事实是，对于REST客户端针对REST服务器进行身份验证的唯一可行的OAuth2授予类型是资源所有者密码凭证（ROPC），因为代码授予和隐式授予要求用户界面/网页（由Auth服务器托管）用户登录并手动授权客户端应用。 ROPC的工作方式是，通过发送资源所有者的用户名/密码和客户端ID作为查询字符串参数？这比基本身份验证（IMHO）更为不安全，基本身份验证至少使用base-64对凭据进行编码，然后将其发送到可以由TLS加密的标头中！所以我问：在公共REST API的上下文中，OAuth2 ROPC是否真的比Basic Auth更好？有什么比OAuth2 ROPC更安全的？更新资料我刚刚读了这篇出色的文章，解释了Amazon针对AWS的非基于OAuth2的REST安全性。从本质上讲，这是一个基于私钥的解决方案，其中，每个REST请求的哈希都将生成，并作为sidecar与常规（未加密）请求一起发送。只有客户端和服务器知道私钥，因此，当服务器接收到该请求（再次包含普通请求+散列请求）时，服务器将查找客户端的私钥，将相同的哈希应用于普通请求，并然后比较两个哈希。这听起来比OAuth2的ROPC更加复杂，复杂和安全！除非我在这里缺少一些重要的东西，否则OAuth2 ROPC只会发送client_id，username并且password作为查询字符串参数...完全完全不安全！这种基于HMAC /哈希的解决方案似乎更加令人印象深刻和安全。问题是，即使是该文章的作者也继续说：您[也会]慢慢意识到并接受在某个时候您将必须实现OAuth ... 巴巴巴哇？！？！如果OAuth2的安全性不如此聪明的基于HMAC /哈希的解决方案，那么为什么本文的作者感到在某些时候需要使用OAuth。我很混乱。

21 rest oauth https

4

如果客户端的高级程度仍然不足以使用REST API，那么对“可发现性”的需求是什么？

我看过的各种讲座以及我在REST上扫描的教程似乎都在强调一种称为“可发现性”的东西。据我有限的理解，该术语似乎意味着客户应该能够http://URL-自动获得其可以做的事情的清单。我难以理解的是-“软件客户”不是人类。它们只是程序，没有直观的知识来理解与所提供的链接的确切关系。只有人可以访问网站并理解所显示的文本和链接并对其进行操作。那么，当访问此类可发现URL的客户端代码实际上无法对其进行任何操作时，除非客户端的人工开发人员实际尝试了所提供的资源，可发现性的意义何在？这看起来与在《文档》手册中定义可用功能集完全一样，只是方向不同，实际上需要为开发人员进行更多工作。为什么第二种预定义可以在实际REST资源外部的文档中完成的工作的方法被认为是次等的呢？

20 rest api hateoas

1

OAuth的替代品？

在将API服务扩展到外部使用者和开发人员时，Web行业正在/已经转向使用OAuth。简单有一些优雅之处。...而且，三步OAuth流程还不错...我只是发现它是一堆糟糕的选择中最好的。是否有其他更好，更安全的替代方案？安全参考来自以下URL： OAuth 2.0对网络不利吗？没有签名的OAuth 2不利于网络我在IT安全性堆栈交换中遇到了这一点，并认为从安全性的角度来看这是很痛苦的： OAuth / OpenID / Facebook Connect ..疯狂吗？也许SAML 2.0是替代方案？那OpenID呢？这个问题的目的是从编程的角度来看。 OAuth是当今存在的最佳选择吗？是否存在替代选项，这些选项使我可以将Web应用程序扩展到从安全角度，实现角度，寿命（不需要几个月的返工）以及更好的支持消费者的Web应用程序，并支持消耗我的Web的移动应用程序应用。

20 web-applications websites rest

5

RESTful体系结构的优缺点

已关闭。这个问题需要更加集中。它当前不接受答案。想改善这个问题吗？更新问题，使其仅通过编辑此帖子来关注一个问题。 5年前关闭。我所见过的关于REST优缺点的最常见讨论倾向于将有关SOAP的讨论框架化。我都没有经验。我目前面临的决定是我的经验不足，这使我难以评估。我开始开发一个具有多个组件的应用程序-主要是一个管理方面，允许所有者管理多个站点-一个面向公众的用户界面，该界面允许用户与主机上保存的数据进行交互。我需要评估允许将后者托管在任何地方并通过RESTful体系结构与前者进行通信的含义，或者要求两个组件都位于同一主机上。开发RESTful架构的关键含义是什么，尤其是在以下方面的功能方面： 1：安全2：性能3：接口复杂性编辑：看这个问题的一些答案-我应该澄清。我不是在寻求与SOAP的比较-而是REST应用程序与所有组件都驻留在一台主机上的应用程序的概述。（尽管感谢您的回答！）

20 web-applications rest

4

是否应使用HTTP状态代码来表示服务器上的业务逻辑错误？

对于客户端（浏览器中的JS）与服务器通信的一些API设计，我处在一个十字路口。由于有效的安全锁定，我们使用HTTP 409冲突来表示操作失败。安全锁可以防止开发人员意外更改我们客户的生产系统。我的任务是在客户端上更优雅地处理409s，以指示为什么特定的API调用失败。我的解决方案是包装我们的任何AJAX调用的失败处理程序，当由于409导致某些操作失败时，它将在客户端上显示通知-一切都很好，并且可以与使用相同机制的其他4XX和5XX错误一起使用。出现问题时，我们的一个路由处理程序在遇到业务逻辑错误时以409s响应-我的AJAX包装器报告安全锁已打开，而客户端的现有故障处理程序报告了（它认为）问题是基于主体的回应。一个简单的解决方案是更改处理程序的响应或用于表示安全锁的状态代码。这使我走到了十字路口：HTTP状态代码是否应该甚至用来表示业务逻辑错误？这个问题解决了我面临的同一问题，但是并没有获得太大的吸引力。正如链接答案中所建议的那样，我倾向于使用HTTP 200 OK以及适当的正文来表示业务逻辑中的失败。有人在这里有什么强烈的意见吗？有谁能说服我这是代表失败的错误方式？

20 rest api web

1

嵌套的REST网址和父ID，哪个设计更好？

好的，我们有两个资源：Album和Song。这是API： GET,POST /albums GET,POST /albums/:albumId GET,POST /albums/:albumId/songs GET,POST /albums/:albumId/songs/:songId 我们知道我们讨厌某首歌，Susy例如。我们应该在哪里search采取行动？另一个问题。好吧，现在更真实了。我们打开专辑1并加载所有歌曲。我们创建了JS对象，每个对象都保存歌曲数据，并具有如下几种方法：remove，update。歌曲对象具有ID，名称和内容，但是不知道它属于哪个父对象，因为我们通过查询来检索歌曲列表，因此每个父对象都返回父ID并不是很好。我错了吗？因此，我看到的解决方案很少，但我不确定。将父ID设为可选-作为get-parameter。我目前使用的是这种方法，但我觉得它很丑。 List,Create /songs?album=albumId Update,Delete /songs/:songId Get /songs/?name=susy # also, solution for first question 混合动力车现在方便了，因为我们需要唱片集ID来执行OPTIONS查询以获取元数据。 List,Create /album/:albumId/songs Update,Delete /songs/:songId POST /songs/search # also, solution for first question 返回每个资源实例的完整URL。API是相同的，但是我们会得到如下歌曲： id: 5 name: 'Elegy' url: /albums/2/songs/5 我听说这种方法称为HATEOAS。所以...提供父母身分证 id: …

20 design design-patterns rest ajax

3

DDD应用程序服务和REST API之间的概念不匹配

我正在尝试设计一个具有复杂业务域和支持REST API（严格来说不是REST，而是面向资源）的应用程序。我想出一种以面向资源的方式公开域模型的方法时遇到一些麻烦。在DDD中，域模型的客户端需要通过过程“应用程序服务”层来访问由实体和域服务实现的任何业务功能。例如，有一个具有两种方法来更新User实体的应用程序服务： userService.ChangeName(name); userService.ChangeEmail(email); 此应用程序服务的API公开命令（动词，过程），而不是状态。但是，如果我们还需要为同一应用程序提供RESTful API，则有一个用户资源模型，如下所示： { name:"name", email:"email@mail.com" } 面向资源的API公开状态，而不是命令。这引起了以下问题：根据REST API上的每个属性，每个针对REST API的更新操作都可以映射到一个或多个Application Service过程调用。对于REST API客户端，每个更新操作看起来都是原子操作，但是并不是那样实现的。每个应用程序服务调用被设计为一个单独的事务。在资源模型上更新一个字段可能会更改其他字段的验证规则。因此，我们需要一起验证所有资源模型字段，以确保所有潜在的应用程序服务调用在开始创建之前都是有效的。一次验证一组命令要比一次执行简单得多。我们如何在甚至不知道存在单个命令的客户端上执行此操作？以不同的顺序调用Application Service方法可能会产生不同的效果，而REST API看起来没有什么区别（在一个资源内）我可以想出更多类似的问题，但是基本上它们都是由同一件事引起的。每次调用应用程序服务后，系统状态都会更改。什么是有效更改的规则，即实体可以执行下一个更改的一组操作。面向资源的API试图使它们看起来都像原子操作。但是跨越这个鸿沟的复杂性一定要到某个地方，而且看起来是巨大的。另外，如果UI更加面向命令（通常是这种情况），那么我们将不得不在客户端的命令和资源之间进行映射，然后再在API端进行映射。问题：所有这些复杂性是否应该仅由（厚）REST到AppService映射层处理？还是我对DDD / REST的理解缺少什么？ REST是否对于在一定程度（相当低）的复杂度下公开域模型功能不可行？

20 architecture rest domain-driven-design

3

解耦胜过REST中的DRY吗？

我正在构建REST API，以公开现有Java API的大部分功能。这两个API都供我的组织内部使用；我不必为外部使用而设计。我对这两种API都有影响，但是正在实现REST。Java API将继续用于本地应用程序（不会“淘汰”），但是REST API将用于重大的新开发。一些Java API类只是数据（带有属性，getter，setter的bean）。并且至少其中一些有意义的是通过REST API以某种形式（作为数据（将被编组为XML或JSON））进行传输。例如，一个存储有关服务器计算机信息的类。对于这些数据类，我面临以下选择：我是否... 直接在REST API中公开原始Java类（或子类），或者专门为REST API创建新的数据传输类（DTO模式）？无论哪种方式，我都会有REST数据传输类。问题是是要注释原始文件还是创建新的文件（可能是原始文件的副本）。可能还有其他选择，但我将主要关注这两个。＃1的参数：干（不要重复自己）实施更快升级REST API更容易＃2的参数：如果REST API需要与Java API分开版本，该怎么办？（这很有可能。）如果Java数据类发生重大更改（例如，删除属性，添加行为或更改类层次结构）怎么办？（这也有可能。）底线是，似乎在DRY（＃1）和去耦（＃2）之间进行了权衡。我倾向于从＃1开始，然后如果出现问题，然后再转到＃2，请遵循不构建无法证明自己需要的敏捷指导。这是一个坏主意吗; 如果我认为我最终还是会从那里开始，我应该从＃2开始吗？我的清单中是否缺少主要的论据/后果？

19 java api rest coupling dry

2

REST API设计：对API的多次调用与单次调用

我们正在开发用于电子商务网站的Rest API，它将由移动应用程序使用。在应用程序的首页中，我们需要调用多个资源，例如滑块，顶级品牌，畅销产品，热门产品等。进行API调用的两个选项：单次通话： www.example.com/api/GetAllInHome 多个通话： www.example.com/api/GetSliders www.example.com/api/GetTopBrands www.example.com/api/GetBestSellingProducts www.example.com/api/GetTrendingProducts 其余api设计的最佳方法是哪种-一次或多次调用，说明优缺点？哪个会花更多时间来响应请求？

19 rest api api-design url

5

RESTful API代表没有东西

想象一下一个API，以确定一个人是否选择了他们的精神动物。他们只能有零个或一个精神动物。目前： /person/{id}/selectedSpiritAnimal 当他们选择了动物时，返回http 200， {selectedAnimal:mole} 但是当他们没有选择时，它将返回http 404。这使我的精神动物不满意，因为我们正在表示一个有效的域问题-尚未选择精神动物-作为HTTP错误。另外，作为一家公司-erm Sprit-Animal-Hampers-R-us，我们想知道某人何时没有选择，以便我们提示他们。什么是更好的回应： HTTP 200和 {selectedAnimal:null} 甚至更明确 HTTP 200和 {selectedAnimal:null, spiritAnimalSelected: false} 还是返回404更好？因为很像this image has not yet been uploaded在线查看图像时将是404。this person has not selected a spirit animal可能是404 该问题已被提议作为重复项，但是当应用程序配置为不允许该URL表示更改时，该问题解决了一个其他有效的URL。而在这里，我正在研究在没有资源的情况下有意义的代表资源的方式。也就是说，客户端请求URL是有效的，并且响应是您已成功请求表示没有东西的资源。因此，这不是“业务逻辑”，而是情况下缺少某物有意义（可能是因为我的许多同事都认为404仍然正确），但是我不确定如何将其映射到规格很难选择答案。我在这里的谈话和正在进行的工作中多次改变主意。在这里为我解决的问题是，规范指出4xx是客户犯错的时间。在这种情况下，已告知客户端期望来自selectedSpiritAnimal url的响应，因此不会出错。我的同事之间的共识是，这是API设计错误的征兆最好只请求/ person / {id}并返回该人的一组链接关系...那么如果没有给您/ selectedSpiritAnimal链接（当一个人没有选择时），但是您不管怎样都称它为404才有意义。或者您实施部分响应并让/ person / {id}返回更完整的文档，除非客户端请求数据的子集

18 rest

3

为什么在Web应用程序中通常使用REST代替类似RPC的机制？

我最近刚开始在一家公司中使用了一个非常不寻常的自定义框架用于其Web应用程序，至少与我所知道的典型Web应用程序框架相比。代替RESTful Web服务，使用RPC机制与服务器进行通信。与服务器通信看起来像一个简单的函数调用，但是该函数在服务器而不是客户端上执行。在服务器端，有一种方法可以定义客户端可以调用的功能。完全抽象了如何将其转换为http请求的细节。我现在只用了很短的时间，但是似乎很方便。但是我想知道我缺少这种方法的缺点。其他人似乎都在做不同的事情，这通常对我来说是一个迹象，表明我可能做的是愚蠢或出色的事情，而前者的几率更高。

18 web-applications rest rpc

1

放置API密钥的位置：自定义HTTP标头与自定义方案的Authorization标头

我正在设计一个通过API密钥使用授权/身份验证的REST API。我试图找出最合适的位置，然后发现许多人建议使用自定义HTTP标头ProjectName-Api-Key，例如： ProjectName-Api-Key: abcde 但在Authorization标头上使用自定义方案也是可能的，从思想上来说也是正确的，例如： Authorization: ApiKey abcde 另一方面，我发现一个考虑，自定义授权方案可能出乎意料，并且不受某些客户端支持，并且无论如何都会导致自定义代码，因此最好使用自定义标头，因为客户对此没有任何期望。您希望以哪种方式发送API密钥？

17 rest api authentication authorization headers

Questions tagged «rest»