TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Ask HN: Is OpenAPI Documentation Superior?

4 点作者 hirokib大约 4 年前
We've been using SlateDocs over at https://butterflylabs.gitlab.io/api-documentation for our documentation. However anytime we see docs, people mention OpenAPI solutions. Outside of the autogenerating aspects, are there benefits for the API consumer?

6 条评论

mooreds大约 4 年前
I&#x27;ve been looking at this (we have a lot of docs and our API docs are all written in asciidoc). I don&#x27;t think the value of OpenAPI is in the documentation, though it seems pretty thorough.<p>There are a lot of benefits for the API producer in terms of tooling and the ecosystem.<p>But that tooling also helps the consumer. Look at all the tools listed here: <a href="https:&#x2F;&#x2F;openapi.tools&#x2F;" rel="nofollow">https:&#x2F;&#x2F;openapi.tools&#x2F;</a> Those that would be helpful to me as a consumer of an API are:<p><pre><code> * Documentation * Learning * Mock servers (for testing) * Some of the tools under misc * SDK Generators. Most people don&#x27;t want to consume an API using REST, they want to use their fav language to do so </code></pre> I asked in a slack full of developer relations folks about alternatives to OpenAPI for defining REST APIs and didn&#x27;t hear any good alternatives.<p>SlateDocs looks really nice, though. As sibling comments have pointed out, you can have both.
评论 #26585196 未加载
bigiain大约 4 年前
&gt; Outside of the autogenerating aspects, are there benefits for the API consumer?<p>Mostly familiarity.<p>The OpenAPI spec and the Swagger tools are something that a _lot_ of devs are familiar with, and they integrate well with lots of other tools (We have OpenAPI docs embedded in out Confluence&#x2F;Jira workflow).<p>That SlateDocs looks nice, but I&#x27;ve never heard of it before.<p>If I had two browser tabs open to evaluate different 3rd party APIs to consume, I&#x27;d somewhat strongly lean towards the one that used OpenAPI, because I know it&#x27;d fit in with our existing toolset and experience.
评论 #26585649 未加载
margor大约 4 年前
There is also <a href="https:&#x2F;&#x2F;apiblueprint.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;apiblueprint.org&#x2F;</a> that I really enjoyed working with even by hand writing the underlying specs and using their proposed docs generators. But it was almost 2 years ago so not sure what is the state of it now.
tdeck大约 4 年前
I&#x27;d say the answer is no. People use OpenAPI because it produces a good result and fits conveniently into a company&#x27;s workflow.<p>The most important aspects of good API documentation are<p>1) correctness,<p>2) thoughtful and complete examples, and<p>3) a clear explanation of the data model and state transitions.<p>These can be accomplished with any tool.
评论 #26585694 未加载
Meic大约 4 年前
You can do both. Widdershins converts an OpenAPI definition to the markdown format used by Slatedocs. <a href="https:&#x2F;&#x2F;github.com&#x2F;mermade&#x2F;Widdershins" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;mermade&#x2F;Widdershins</a>
评论 #26587663 未加载
评论 #26600158 未加载
评论 #26585672 未加载
tobilg大约 4 年前
You might also look at <a href="https:&#x2F;&#x2F;github.com&#x2F;tobilg&#x2F;api2html" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;tobilg&#x2F;api2html</a>
评论 #26585661 未加载