Questions tagged «api-design»

已关闭。这个问题需要更加集中。它当前不接受答案。 6年前关闭。 已锁定。该问题及其答案被锁定，因为该问题是题外话，但具有历史意义。它目前不接受新的答案或互动。 出色的API使它们变得如此出色的原因是什么？我认为坚持“做一件事情，做好一件事情”的口号是一个好兆头，良好地映射到问题域很重要，但是出色的API有什么共同点？

15 api-design 

我一直在开发将支持许多用户的应用程序。问题是我不知道如何验证客户端/用户。 我正在构建一个http://quickblox.com/之类的应用程序，在该应用程序中我将向用户提供凭据，他们将使用这些凭据来构建N个应用程序，在这些应用程序中，他们无法输入用户名和密码来进行身份验证。 让我们假设它如下。（就像QuickBlox一样） 1.用户在我的网站上创建帐户。 2.用户可以创建N个API密钥和保密凭证。（对于多个应用程序） 3.用户将在其应用程序（Android，iOS，Javascript等）中使用这些凭据与我的REST API进行通信。（REST API具有读写访问权限。） 我的顾虑？ 用户会将其凭据（API密钥和秘密密钥）放入他们构建的应用程序中，如果有人获得了这些密钥并尝试模仿用户该怎么办？（通过反编译APK或直接查看JavaScript代码。 我在某处错了吗？我对构建这种三级用户机制感到困惑。

14 design-patterns  architecture  api-design  authentication  enterprise-architecture 

我正在设计服务的REST API，并陷入了嵌套资源的正确方法。 资源：合作伙伴，票证，设置 资源之间的联系： 伙伴有很多票， 合作伙伴有一组设置， 业务逻辑： 您可以将所有合作伙伴列为匿名用户， 您可以将新票证添加为指定合作伙伴的匿名用户， 只有伙伴可以列出他的门票， 只有合作伙伴可以修改票证， 只有合作伙伴可以列出设置， 只有合作伙伴可以修改设置， 到目前为止，我所做的是： 合作伙伴资源 GET / partners-列出所有合作伙伴 GET / partners /：id-显示由：id参数指定的合作伙伴的详细信息 GET / partners /：partner_id / tickets-合作伙伴的票据列表 GET / partners /：partner_id / tickets /：id-详细信息指定伙伴的工单的 POST / partners /：partner_id / tickets-保存新工单 PUT / partners /：partner_id / tickets /：id-更新由：id参数指定的工单 GET / …

14 api  rest  api-design 

Sue正在设计一个JavaScript库Magician.js。它的关键是Rabbit从传递的参数中拉出一个函数。 她知道它的用户可能想从a String，a Number，a Function甚至甚至是a中拔出一只兔子HTMLElement。考虑到这一点，她可以这样设计API： 严格的界面 Magician.pullRabbitOutOfString = function(str) //... Magician.pullRabbitOutOfHTMLElement = function(htmlEl) //... 上面示例中的每个函数都知道如何处理函数名称/参数名称中指定的类型的参数。 或者，她可以这样设计： “临时”界面 Magician.pullRabbit = function(anything) //... pullRabbit必须考虑该anything参数可能具有的各种不同的预期类型，以及（当然）意外类型： Magician.pullRabbit = function(anything) { if (anything === undefined) { return new Rabbit(); // out of thin air } else if (isString(anything)) { // more } else if (isNumber(anything)) …

14 javascript  api  api-design 

根据这个人说的话：http : //toddfredrich.com/ids-in-rest-api.html 假设他关于使用UUID识别api资源是正确的。然后我遇到麻烦，尝试以这种方式实现它，这是： class FooEntity { final String id = null; //auto-generated by my backend (mongodb), not shared final UUID uid = UUID.randomUUID(); //the resource id } （在客户端和服务器之间，发送和接收DTO，而不是数据库实体。） 现在的问题是，这id不再有用，因为我不再使用它。客户端发出请求，uid所以为什么还要打扰2个id？然后我们回到开始的同一期。如果我将UUID设置为主键（_id），那么我会将后端ID公开。 除此之外，还有效率主题。我已经读过，通过ObjectId进行索引比UUID效率更高。

14 database  api-design  mongodb 

我们有一个ASP.NET Web API，它为我们的单页应用程序提供了REST API。我们使用DTO / POCO通过此API传递数据。 现在的问题是，随着时间的推移，这些DTO越来越大，所以现在我们要重构DTO。 我正在寻找如何设计DTO的“最佳实践”：当前，我们有一些小的DTO，它们仅包含值类型字段，例如： public class UserDto { public int Id { get; set; } public string Name { get; set; } } 其他DTO按组成使用此UserDto，例如： public class TaskDto { public int Id { get; set; } public UserDto AssignedTo { get; set; } } 另外，还有一些扩展的DTO是通过从其他对象继承来定义的，例如： public class …

13 rest  api-design  web-api  dto  poco 

我一直在进行有关RESTful Web服务设计的研究，我已经达到了我认为是关键的决策点，因此我想将其提供给社区以获取一些建议。 为了遵循RESTful架构的原则，我想提供一个可发现的API，因此我将尽可能全面地支持各种HTTP动词。我的困难在于选择这些资源的表示形式。您会发现，我很容易想出自己的API，该API涵盖了如何显示搜索结果以及如何提供与其他资源的链接，但这对我的应用程序来说是唯一的。 我已经阅读了有关Atom发布协议（RFC 5023）的信息，以及OData如何促进其使用，但它似乎为（当前）一个相当简单的API增加了额外的抽象层次。 所以我的问题是，开发人员何时应该选择AtomPub作为表示形式的选择-如果有的话？如果不是，当前推荐的方法是什么？

13 web-services  rest  api-design 

我正在阅读《依赖注入原理，实践和模式》一书，并了解了泄漏抽象的概念，该概念在本书中有很好的描述。 这些天来，我正在使用依赖注入重构C＃代码库，以便使用异步调用而不是阻塞调用。这样做时，我正在考虑一些接口，这些接口在我的代码库中表示抽象，并且需要重新设计以便可以使用异步调用。 例如，考虑以下接口，它代表应用程序用户的存储库： public interface IUserRepository { Task<IEnumerable<User>> GetAllAsync(); } 根据书中的定义，泄漏抽象是设计时考虑到特定实现的抽象，因此某些实现详细说明了抽象本身的“泄漏”。 我的问题如下：我们可以考虑以异步方式设计的接口（例如IUserRepository）作为泄漏抽象的示例吗？ 当然，并非所有可能的实现都与异步有关：只有进程外实现（例如SQL实现）才需要同步，但是内存中存储库不需要异步（实际上实现接口的内存中版本可能更多）如果接口公开异步方法很困难，例如，您可能必须在方法实现中返回类似Task.CompletedTask或Task.FromResult（users）之类的东西。 您如何看待？

13 c#  object-oriented  api-design  interfaces  dependency-injection 

我已经来回切换了约5次。这个REST端点/api/tags/仅供内部使用（没有第三方客户端），我是唯一使用它的人。 我要在这两种表示形式之间做出决定： 平面 { "types":[ { "id":1, "text":"Utility" }, { "id":7, "text":"Lease Terms" }, ], "tags":[ { "id":8, "text":"Water", "type":1 }, { "id":9, "text":"Electricity", "type":1 }, { "id":5, "text":"Minimum 12 month lease", "type":7 }, { "id":17, "text":"lease negotiable/flexible", "type":7 }, ] } 它有点模块化。可以添加另一个顶层，例如“国家/地区”而不会破坏兼容性。 巢状 { "1":{ "text":"Utility", "tags":{ "8":{ "text":"Water" …

12 rest  api-design  json 

我正在设计一个RESTful API，并遇到标题问题，为清楚起见已重述： 如果客户端发送无法识别的参数，我应该快速失败吗？例如， http://example.com/api/foo?bar=true&paula=bean 在上面，bar是有效参数，但paulaAPI未指定。我是不是该 警告客户错误 快速失败 忽略它 如果我警告客户端，我只能对第一个参数发出警告，因为它们可能发送的数量几乎是无限的，并且服务器可能要做的更好。同样，失败时，只会将第一个无效参数指定为问题。 我更喜欢失败而不是发出警告来迫使程序员采取行动，因为否则他们可能会忽略问题并继续浪费资源，或者最终不经意地养成自己。在这方面什么都不做会更糟。 我的论点有意义吗？在这种事情上有公认的做法吗？

12 rest  api-design 

我正在研究从Python到Rust的移植，并遇到了一些代码，这些代码在Rust中无法像在Python中那样自然地表达。 一种情况是使用默认参数： class Foo: def __init__(self, a="Hello"): self._a = a 在Rust中，您可以使用构建器来实现： struct FooBuilder { a: &'static str, } struct Foo { _a: &'static str } impl FooBuilder { fn new() -> FooBuilder { FooBuilder { a: "Hello", } } fn change_a(self, new_a: &'static str) -> FooBuilder { FooBuilder { a: …

12 api-design  porting 

我正在设计HTTP API，希望使其尽可能地具有RESTful风格。 有些动作的功能会散布在一些资源上，有时需要撤消。 我以为自己，这听起来像是命令模式，但是我如何将其建模为资源呢？ 我将介绍一个名为XXAction的新资源，例如DepositAction，它将通过这样的方式创建 POST /card/{card-id}/account/{account-id}/Deposit AmountToDeposit=100, different parameters... 这实际上将创建一个新的DepositAction并激活它的Do / Execute方法。在这种情况下，返回201 Created HTTP状态表示操作已成功执行。 之后，如果客户希望查看操作细节，则可以 GET /action/{action-id} 我猜应该阻止Update / PUT，因为此处不相关。 为了撤消操作，我想到了使用 DELETE /action/{action-id} 实际上将调用相关对象的Undo方法，并更改其状态。 假设我只对一次“撤消”感到满意，而无需重做。 这种方法可以吗？ 有什么陷阱，不使用它的原因吗？ 从客户的观点看是否明白？

12 design-patterns  api  rest  api-design  http 

我正在寻找一个很好的资源来学习C ++库的良好API设计，查看共享的对象/ dll等。在源代码级别上有很多资源可以编写漂亮的API，漂亮的类，模板等，但是几乎没有将它们放到共享的库和可执行文件中。约翰·拉科斯（John Lakos）的《大规模C ++软件设计》一书很有趣，但已经过时了。 我正在寻找的是关于处理模板的建议。在API中使用模板后，我通常会在可执行文件（或其他库）中获得库代码，因此，如果在那里修复错误，我将无法简单地推出新库，而必须重新编译和重新分发该代码的所有客户端。（是的，我知道一些解决方案，例如尝试实例化至少库中最常见的版本等）。 我还在寻找其他注意事项和在C ++库上保持二进制兼容性时需要注意的事项。 是否有一个很好的网站或关于此类事情的书？

12 c++  libraries  api-design  dll 

例如，我有以下实体：客户，报告。客户可能有很多报告，我认为单个报告管理的端点应该像这样嵌套： /clients/{client_id}/reports/{report_id} 至于一位客户的所有报告，预期会： /clients/{client_id}/reports 但是应该如何寻找一个端点来获取所有客户端的所有报告，以保持API的一致性和良好的设计。 我的方法： （我在某些Google API中看到了它）使用“-”代替它，并将其解析为“全部”： /clients/-/reports 这使端点格式保持不变，但看起来有点不正常，找不到任何以此方式建议的rfc。 为所有报告创建一个单独的端点： /reports 但是要获得客户报告，它仍然是： /clients/{client_id}/reports 重构端点以使“客户端”不是父代，而只是一个过滤器参数： /reports?client={client_id} -一位客户的报告 /reports -所有客户的报告 如果添加新的端点以发布特定客户端的报告，则该外观可能很难看，因为它将是带有URL中参数的POST请求。 还有其他建议吗？

12 rest  api  api-design 

我看到很多问题都与访问使用连字符（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