Questions tagged «web-api»

已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗？更新问题，以便通过编辑此帖子以事实和引用的形式回答。 4年前关闭。 编辑：如果您不熟悉odata，请前往这里。 我正在尝试确定是否值得学习这项技术，或者它是否会流行。 前提很有趣，作为API的开发人员，这似乎是向使用它们的开发人员提供更大灵活性的好方法。 不幸的是，在过去的几年中，我对开放数据协议没有太多的“嗡嗡声”，因此只是尝试评估一下一旦我学会了它，它是否有可能出现。 提前致谢。

13 api  web-api  standardization 

我看到很多问题都与访问使用连字符（kebab-case）的JSON密钥有关，但是现在我发现自己想知道应该在我的密钥中坚持使用camelCase还是snake_case。我知道连字符在语言之间移植时也会产生复杂的映射。我已经看到一些JSON反序列化库将这些键转换为camelCase样式。 例： var something = { "some-value": 'thing' } VS var something = { "someValue": 'thing', "some_other_value": 'thing_two' }

12 javascript  api  api-design  json  web-api 

我正在尝试将一组基于SOAP的服务转换为RESTful API。 我首先通过分析操作名称来识别资源，然后获得了资源Subscription。 当我需要更新订阅的状态时，不能直接向POST服务器发送请求，因为我没有直接访问资源的权限，但是我需要调用一些RPC样式的操作来更新其属性。此外，仅且仅当我将订阅状态更改为“活动”时，才需要对外部服务的附加调用。 在这些情况下，处理基础操作的最佳实践是什么？ 我想出的解决方案是使用查询参数，这样，如果我需要调用激活服务，则可以使用以下方法： POST /subscriptions/{subscriptionid}/?activate=true 考虑到我不能直接更新我的订阅对象字段，是否有最佳实践来处理这种转换？ 更新1： 我可以在POST请求的正文中放入一些值，例如“ state”：“ active” 并检查我的服务中要触发的正确操作。

11 rest  web-services  api-design  web-api 

我经常在HTML文档中看到以下内容 <link rel="self" href="http://example.com/something"> 或像这样的JSON link: { rel="self", href="http://example.com/something" } 或XML <atom:link rel="self" href="http://example.com/something" /> 所以我有一些问题： 为什么要包含此链接？它带来什么好处？（请告诉我这是有原因的，而不仅仅是“好的做法”护身符） 如何在客户中利用此链接？此链接的用例是什么？ 我什么时候不应该使用此链接？什么时候包括它毫无意义？

11 rest  web-api 

我正在创建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 

我必须设计一个“小部件”，一个脚本，合作伙伴将其嵌入到他们的网站中以显示一些UI并调用我们的API。 基本上，它将根据API调用中提供的一些ID在这些网站上显示我们的数据。我们要避免的是有人滥用API并使用它来刮擦我们的整个目录。 嵌入脚本的每个合作伙伴都将获得一个公开密钥，在调用API时必须提供该公开密钥。一个想法是让他们在加载脚本时附加此密钥，例如： <script src="//initrode.com/widget/loader.js?key=xxxx"></script> 这样，对脚本的请求可用于注册密钥/源IP对，并仅在密钥/ IP对与已注册的密钥/源IP对匹配（生命周期有限且每天的请求受到限制）时才应答后续的API调用。 我不确定这是个好主意，因为通过混淆显然是安全的（有人重新加载脚本会完全绕过它）；但我没有其他限制访问的方法。我不能为每个用户提供唯一的密钥，只能给合作伙伴提供。我不能使用私钥系统，因为任何人都可以使用所有代码。它基本上是限制对公共API的访问，即在定义上是矛盾的。 您如何看待该解决方案，您将如何应对这些约束？

10 security  api-design  web-api 

我对我的Web应用程序的设计有严重的怀疑。 我想将业务逻辑与接口分开，所以我制作了一个Web API，用于处理对数据库的所有请求。 它是具有实体框架，工作单元和通用存储库模式的ASP.NET Web API。到目前为止，一切都很好。 问题 我需要帮助的地方是，我找不到在API和应用程序之间共享对象的有效方法。 我不想直接序列化实体对象，我认为这将是一个坏习惯，因为如果实体模型发生更改，我最终可能会无缘无故地序列化大型对象。 现在如何实施 因为我的接口是C＃中的ASP.NET Web应用程序，而我的API是C＃中的API，所以我创建了一个公共库，其中定义了我想在它们之间共享的所有类。 我知道当我开发一个Android应用程序时该解决方案将不起作用，我将不得不再次用Java创建类，但这不是我最大的问题。 问题是我感觉自己一直在转换对象。 例 这是我的工作流程示例： 我从包含所有对象和表单数据注释的模型开始，然后用户将模型发布到控制器。 在控制器中，我必须将此模型转换为我的公共库中的类，然后将该对象发送到我的API。 然后，我的API中的控制器捕获了该调用，并将该对象转换为实体对象以更新数据库。 所以我有3节课 视图的模型以及用于验证的所有数据注释（客户端） 共享对象的公共库类（DLL） 实体类（API） 我感觉自己做错了什么。还有更优雅的东西吗？我想确保在这个项目变得太大之前，我有一个很好的解决方案。

9 design  design-patterns  web-development  web-api