Questions tagged «api»

在系统之间（业务级别）讨论API时，我们团队中通常有两种不同的观点：有些人更喜欢（可以说）通用抽象方法，而另一些则是直截了当的“具体”方法。 示例：设计一个简单的“人员搜索” API。具体的版本是 searchPerson(String name, boolean soundEx, String firstName, boolean soundEx, String dateOfBirth) 支持具体版本的人说： API是自我记录的 很容易理解 易于验证（编译器或作为Web服务：模式验证） 吻 我们团队中的另一组人会说“那只是搜索条件列表” searchPerson(List<SearchCriteria> criteria) 与 SearchCritera { String parameter, String value, Map<String, String> options } 可能使某些枚举类型的“参数”。 支持者说： 在不更改API（声明）的情况下，实现可以更改，例如添加更多条件或更多选项。即使在部署时也没有同步这样的更改。 即使使用具体的变体，也需要文档 模式验证被高估了，通常您需要进一步验证，模式无法处理所有情况 我们已经有一个与其他系统类似的API-重用 相反的论点是 有关有效参数和有效参数组合的大量文档 需要更多的沟通工作，因为其他团队更难以理解 有没有最佳做法？文献？

25 api  web-services  api-design 

我经常听到人们说C ++程序员应该将其库/产品的公共API公开为C API。 这是什么意思，它的优点是什么？

25 c++  c  api 

我正在使用MVC模式构建Web应用程序。遵循这种架构，我们可以看到模型中使用了与数据库交互的所有方法。 但是，如果我必须打电话给其他人在网络上公开的服务会怎样？例如，我想访问Facebook API以获取页面的所有关注者，那么，将这些方法放在哪里？ 显然，视图不是一个好主意，因为该模块专用于表示，不应使用控制器来检索数据，而模型通常仅用于与数据库的交互。 那么，您能给我一些提示吗？而且，请问我是否对MVC架构犯了一些错误？

25 mvc  api 

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

24 terminology  rest  api  http 

每当我遇到新的API或编程语言，甚至是简单的Linux 手册页时，我总是（从我记得以来）就避免使用它们，而是懒惰地依靠示例来理解新概念。 在潜意识中，无论文档/ API不是简单明了，晦涩难懂还是无聊，我都会避免使用它。自从我开始编程已经有好几年了，现在我觉得我需要修正自己的方式，因为我现在意识到我要避免阅读晦涩难懂的文档，从而造成更大的损失，因为它仍然比官方示例高一百万倍文档的覆盖面比那里的任何示例都多。即使意识到这一点，示例也应被视为“附加”价值，而不是“主要”学习资源。 我该如何改掉作为程序员的这种坏习惯？

23 programming-practices  api 

假设系统中有一个带资源的Web应用程序，以及另一个具有类似资源的远程应用程序的引用，那么您如何表示双向同步操作，该操作将“本地”资源与“远程”资源同步？ 例： 我有一个代表待办事项清单的API。 GET / POST / PUT / DELETE / todos /等 该API可以引用远程TODO服务。 GET / POST / PUT / DELETE / todo_services /等 我可以通过我的API作为代理通过远程服务来处理待办事项 GET / POST / PUT / DELETE / todo_services / abc123 /等 我希望能够在本地待办事项集和远程待办事项集之间进行双向同步。 以一种rpc的方式， POST / todo_services / abc123 / sync / 但是，在“动词很糟糕”的想法中，是否有更好的方法来表示此动作？

23 api  rest  api-design  synchronization 

已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗？更新问题，以便通过编辑此帖子以事实和引用的形式回答。 4年前关闭。 我今天勉强通过了Java编程考试。我不得不回答一些关于线程的一般问题，这些问题做得很好，并且编写了一个更糟糕的线程程序。我必须将笔记本电脑连接到投影仪屏幕并立即编写程序。我的第一次尝试是使用匿名类，但我忘记了确切的语法。也许是因为有些激动，或者是因为最近两周我主要使用php进行编码。然后我问是否可以使用API​​文档。答案是“否”。所以我决定走另一条路，实现了Runnable。该程序正在执行最后要求的操作。当然，考官注意到我的第一次失败，这极大地影响了我的分数。令我惊讶的是它不允许使用API​​文档。 因此，我的问题是：没有API文档就可以完美地进行编码真的重要吗？我应该发展这项技能吗？在现实世界和工作环境中真的重要吗？在编程课程中，我专注于学习模式，开发编写良好的设计应用程序的技能，使用API​​的技能并快速找到必要的信息。我并不是想学习如何在没有API文档的情况下进行编程。在工作面试中必须具备（没有API文档的编码）吗？

22 java  self-improvement  api  skills 

假设您正在考虑将应用程序分解为服务。是否有充分的理由采用SOA方法，而不是仅仅创建一个可以由需要它的应用程序加载的库API。

22 api  soa  services 

我正在创建新的业务Web应用程序，并且想要实现： 使用各自领域的最佳技术。我想要具有可靠ORM的可靠后端框架。我想要最先进的SPA（单页应用程序）框架，并为前端应用程序使用最新的HTML和Javascript功能 公开后端实体和业务服务以供不同类型的应用程序使用，例如，Web应用程序，移动（Android）以及可能的其他类型（智能设备等） 因此，为了满足这两个要求，我倾向于将我的应用程序完全隔离在后端和前端应用程序中，并使用REST API（JSON）来组织它们之间的通信。这是合理的方法吗？ 这种分离并不是显而易见的设计解决方案，因为许多Web应用程序技术都集成了视图层，其中服务器端应用程序或多或少地控制视图的生成并部分处理视图的响应（例如，带有视图层的SpringMVC，带有视图的PHP Yii Java JSF / Facelets层将其组件的状态完全保存在服务器上）。因此-周围有许多技术提出了更强的耦合性，并有望缩短开发时间和提供更标准的路径。所以-在开始以未广泛使用的方式使用技术时，我必须谨慎。 据我了解，完全分离的SPA前端通常是由使用第三方API引起的。但是，当后端和前端都由一家公司开发时，这种去耦声音设计是否有效？ 我目前选择的技术是Java / Spring后端和Angular2 / Web组件/聚合物前端-如果允许我这么说的话。但这与这个问题无关，因为这个问题是关于一般设计而不是具体技术的选择？

21 design  rest  api  front-end  backend 

我是编程的新手（我是行业的机械工程师），并且在停机期间正在开发一个小程序，该程序将根据工厂周围各个人员的输入生成一个（solidworks）零件。 仅基于少量输入（准确地说是6个），我需要进行数百个API调用，每个API调用最多可以包含十二个参数。所有这些都是我在采访处理零件的每个人之后收集的一组规则所产生的。我的代码的规则和参数部分为250行，并且还在不断增加。 那么，保持我的代码可读性和可管理性的最佳方法是什么？如何分隔我所有的幻数，所有规则，算法和代码的程序部分？如何处理非常冗长而细致的API？ 我的主要目标是能够在没有我输入的情况下将我的消息传递给某人，并让他们了解我在做什么。

21 api  readability  business-rules 

最近，我一直在开发自己的API，随着对API设计的投入，我一直对如何改善API设计非常感兴趣。 出现了几个方面（不是我的API用户使用，而是在我对该主题的观察讨论中）：一个人应该只通过查看调用API的代码来知道它在做什么。 例如，请参见GitHub上有关此讨论的讨论，例如： foo.update_pinned(true, true); 仅仅通过查看代码（不知道参数名称，文档等），就无法猜测它会做什么-第二个参数是什么意思？建议的改进措施如下： foo.pin() foo.unpin() foo.pin_globally() 这就清除了一切（我猜第二个参数是是否全局固定foo），在这种情况下，我同意后者肯定会有所改进。 但是我相信，在某些情况下，设置不同但与逻辑相关的状态的方法最好作为一个方法调用而不是单独的方法公开，即使您仅通过查看代码也不知道它在做什么。（因此，您必须求助于参数名称和文档以查明-如果我不熟悉API，我个人将始终这样做）。 例如，我SetVisibility(bool, string, bool)在FalconPeer上公开了一种方法，并且我承认只看了一下这一行： falconPeer.SetVisibility(true, "aerw3", true); 您将不知道它在做什么。它设置了3个不同的值来控制falconPeer逻辑上的“可见性” ：仅接受接受密码的加入请求，然后回复发现请求。将其分为3个方法调用可能会导致API的用户设置“可见性”的一个方面而忘记设置其他设置，而我仅通过公开一种方法来设置“可见性”的所有方面而迫使他们考虑。此外，当用户想要更改一个方面时，他们几乎总是会想要更改另一个方面，现在可以在一个呼叫中进行更改。

20 programming-practices  naming  api  api-design 

在一本OS书中，我刚刚读到“公共API永远存在：只有一次实现它的机会”。是真的吗 它仅适用于操作系统的API还是其他API？例如，对于Tasker，Locale和Pushover等Android应用程序的API，这是否正确？

20 android  api  api-design 

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

20 rest  api  hateoas 

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

20 rest  api  web 

最近，我了解了GraphQL，它声称比RESTful更好。但是，我开始怀疑为什么不将SQL语句简单地放入HTTP GET请求中。 例如，在GraphQL中，我将编写 { Movie(id: "cixos5gtq0ogi0126tvekxo27") { id title actors { name } } } 这并不比它的SQL比较简单 SELECT id, title FROM movies WHERE id = cixos5gtq0ogi0126tvekxo27; SELECT actors.name FROM actors, actors_movies WHERE actors.id == movies.actor_id AND movie.id == cixos5gtq0ogi0126tvekxo27; 也许我们可以对查询进行URL编码并发送到服务器 GET endpoint?q=SELECT%20id%2C%20title%20FROM%20movies%20WHERE%20id%20%3D%20cixos5gtq0ogi0126tvekxo27%3B%0ASELECT%20actors.name%20FROM%20actors%2C%20actors_movies%20WHERE%20actors.id%20%3D%3D%20movies.actor_id%20AND%20movie.id%20%3D%3D%20cixos5gtq0ogi0126tvekxo27%3B HTTP/1.1 是的，查询URL可能太长，但是如果您不关心REST遵从性，则可以将其放入POST请求的正文中。（顺便说一句，我认为需要对REST进行HTTP RFC的修订才能有意义：限制查询字符串的长度从一开始就将实现与规范混合在一起） 从客户端直接发出SQL的优势还在于 解析GraphQL不需要服务器端代码/库，从而减少了开发时间。 解析GraphQL不需要服务器端开销，从而减少了运行时间。 SQL语句比GraphQL灵活得多，因为（在大多数情况下）GraphQL无论如何都会简化为SQL。 每个人都知道SQL。 那么，GraphQL与SQL相比有什么优势？

20 architecture  database  web-development  api  web-services