Questions tagged «http»

我正在使用WebApi设计RESTful Web服务，并且想知道在更新/创建对象时返回哪些HTTP响应和响应主体。 例如，我可以使用POST方法将一些JSON发送到Web服务，然后创建一个对象。然后，将HTTP状态设置为“创建”（201）或“确定”（200），并简单地返回诸如“添加了新员工”之类的消息，或者返回最初发送的对象，是最佳实践吗？ PUT方法也是如此。哪种HTTP状态最适合使用，我是否需要返回创建的对象或仅返回一条消息？考虑到用户知道他们无论如何都试图创建/更新对象的事实。 有什么想法吗？ 例： 添加新员工： POST /api/employee HTTP/1.1 Host: localhost:8000 Content-Type: application/json { "Employee": { "Name" : "Joe Bloggs", "Department" : "Finance" } } 更新现有员工： PUT /api/employee HTTP/1.1 Host: localhost:8000 Content-Type: application/json { "Employee": { "Id" : 1 "Name" : "Joe Bloggs", "Department" : "IT" } } 回应： …

36 rest  http 

我们的网址格式如下 / 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 

我知道在通过IP地址使用cookie方面，我们还有其他优势，但是我的问题是，为什么容器不能只记住客户端的IP地址，以便在他再次访问客户端时识别客户端？容器是否可以借助IP地址记住客户端？

26 http  session  networks  cookies  client-server 

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

24 terminology  rest  api  http 

此问题已从“服务器故障” 迁移而来，因为可以在软件工程堆栈交换中进行回答。 迁移 6年前。 我目前正在实现HTTP API，这是我的第一次。 我已经花了很多时间在Wikipedia页面上查看HTTP状态代码，因为我决心在正确的情况下实现正确的代码。在该页面上列出的是编号为420的代码，这是Twitter用来限制速率的自定义代码。 但是，已经存在用于速率限制的代码。是429。 这使我想知道为什么在已经存在用例的情况下，他们为什么要设置自定义的呢？那只是可爱吗？如果是这样，那么在什么情况下可以接受返回不同的状态代码，客户可能会遇到什么问题呢？ 我在某个地方读到Mozilla并未实现笑话418: I’m a teapot响应，这使我认为客户端选择了他们实现的状态代码。如果这是真的，那么我可以想象Twitter的有趣之处可以增强您的冷静代码带来的麻烦。 除非我弄错了，否则我们可以使用任何代码号来表示我们喜欢的任何东西，并且只有约定表明404表示未找到，而429表示则很容易。

24 api-design  http 

我正在更深入地开发RESTful API，到目前为止，已经与一些不同的框架合作来实现这一目标。当然，我遇到了同源策略，现在我想知道Web服务器（而不是Web浏览器）如何实施它。据我了解，浏览器端似乎发生了一些强制执行（例如，遵守从服务器收到的Access-Control-Allow-Origin标头）。但是服务器呢？ 例如，假设一个Web服务器托管了一个访问API的Javascript Web应用程序，该API也托管在该服务器上。我假设服务器将执行同源策略---以便仅允许该服务器上托管的javascript访问API。这样可以防止其他人为该API编写JavaScript客户端并将其托管在另一个网站上，对吗？那么，Web服务器如何能够阻止恶意客户端，该客户端试图声称对其API端点发出AJAX请求，同时声称正在运行源自同一Web服务器的javascript？最受欢迎的服务器（Apache，nginx）如何防御这种攻击？还是我对此的理解不合时宜？ 还是跨域策略仅在客户端实施？

24 web-development  security  ajax  http  xmlhttprequest 

我正在为一个项目设计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 

假设我有一家公司对互联网上最可爱的猫进行排名。 我提供的资源/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 

因此，我正在创建Google App Engine应用程序，并且多次遇到“公开”一词，例如“您的第一个应用程序可以使用基于HTTP的API公开对象”和“通过REST API”。“暴露”是什么意思？是否有与之相关的特定动作，或者它是设计的抽象部分？

18 api  http  google-app-engine 

我在HTTP标头中使用JWT令牌来验证对资源服务器的请求。资源服务器和身份验证服务器是Azure上的两个单独的辅助角色。 我不能决定应该将请求存储在令牌中还是将请求附加到请求/响应中。Claims列表影响客户端UI元素的呈现以及对服务器上数据的访问。因此，在处理请求之前，我想确保服务器收到的声明是真实的并经过验证的。 声明示例包括：CanEditProductList，CanEditShopDescription，CanReadUserDetails。 我要为其使用JWT令牌的原因是： 更好地防止客户端对声明进行编辑（即入侵声明列表）。 无需在每个请求上查找索赔。 我不想使用JWT令牌的原因： 然后，身份验证服务器必须知道以应用程序为中心的声明列表。 令牌成为黑客入侵的单一点。 我读过几句话说，JWT令牌不用于应用程序级数据。 在我看来，两者都有缺点，但是我倾向于将这些声明包含在令牌中，并且只想由以前处理过此问题的人员来处理。 注意：我将对所有API请求使用HTTPS，因此在我看来，令牌将“足够”安全。我正在使用AngularJS，C＃，Web API 2和MVC5。

18 security  http  authentication  authorization 

我正在设计一个新的Web应用程序，该应用程序由REST后端和HTML + JS前端提供支持。 它具有一个POST方法来更改一个实体（我们称为Config），这在应用程序的许多元素的状态下具有多种副作用。假设以这种方式执行POST： POST /api/config BODY {config: ....} 因此，我想在进行这些更改之前显示预览，以使最终用户能够注意到要更改的内容。 我首先想到的是为预览创建一个GET端点，发送实体新状态的主体。这条路： GET /api/preview/items BODY {config: ....} 可能显示具有新配置的项目的新状态。 GET /api/preview/sales BODY {config: ....} 可能会使用新配置显示销售的新状态。 使用GET动词似乎是个好主意，因为我不会更改应用程序的状态。然而，随着使用请求主体的GET请求似乎气馁。 有什么好的做法吗？其他选择可能是使用一种方法将配置存储为草稿，并使用其他方法显示结果，但这将需要额外的步骤，并且必须在服务器中管理草稿： POST /api/preview/config BODY {config: ....} GET /api/preview/items?idPreviewConfig=1

17 programming-practices  rest  http 

我正在构建一个使用JWT令牌进行用户身份验证的RESTful API（由login端点发出，然后在所有标头中发送），并且需要在固定时间后刷新令牌（调用renew端点，该端点将返回更新的令牌） ）。 用户的API会话有可能在令牌到期之前变得无效，因此我的所有端点都首先检查以下各项：1）令牌仍然有效，以及2）用户会话仍然有效。由于客户端将令牌存储在本地，因此无法直接使令牌无效。 因此，我所有的端点必须向我的客户发出两种可能情况的信号：1）是时候续订令牌了； 2）会话已变为无效，并且不再允许它们访问系统。我可以想到两种替代方法，当两种情况之一发生时，我的端点可以向其客户端发出信号（假设客户端可以适应任一选项）： 如果会话无效，则返回http 401代码（未经授权），或者在令牌到期且需要调用renew端点时返回412代码（前提条件失败），这将返回200（正常）代码。 返回401，表示会话无效或令牌已过期。在这种情况下，客户端将立即调用该renew端点，如果它返回200，则刷新令牌，但是如果renew还返回401，则意味着该客户端不在系统之外。 您会推荐上述两种选择中的哪一种？哪一个会更标准，更容易理解和/或更RESTful？还是您会建议完全不同的方法？您发现这两种选择有明显的问题或安全隐患吗？如果您的答案包括支持您的观点的外部参考，则可以加分。 更新 伙计们，请关注一个真正的问题- 表示续订/会话无效的两个http代码替代方案中哪一个最好？不要介意我的系统使用JWT 和服务器端会话的事实，这是我的API针对非常特定的业务规则的特性，而不是我正在寻求帮助的部分;）

17 design  rest  web-services  http  authentication 

如标题所示，我想编写一个HTTP服务器。我的问题是，我该怎么做？我知道这听起来很笼统，而且太“高级”，但是有一种疯狂的方法。我认为，这个问题的答案应该与语言无关。含义，无论我使用哪种语言（例如C，C ++，Java等），答案都应该相同。我对这应该如何工作有一个大致的了解： 打开端口80上的套接字。 等待客户提出请求。 阅读请求（即此人想要页面“ contact-us.html”）。 查找并阅读“ contact-us.html”。 发送html标头，然后发送“ contact-us.html”的内容 完成 就像我说的那样，我相信这是过程，但是我不确定100％。这使我想到了问题的核心。一个人如何或在哪里找到此信息？ 如果我不想只写HTTP服务器怎么办，如果我不想写FTP服务器，聊天服务器，图像查看器等怎么办？一个人如何找到创建可用的HTTP服务器所需的确切步骤/过程？ 一位同事告诉我有关html标头的信息，所以没有他我再也不会知道这一点。他还说了一些有关将每个请求移交给新线程的内容。是否有一些有关工作原理的大书？是否有使用HTTP服务器所需的一些手册？ 我尝试谷歌搜索“ HTTP服务器如何工作”，但我只能找到针对普通百姓的答案，而不是针对希望对HTTP服务器进行编程的人。

17 language-agnostic  server  http