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

科技回声

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

GitHubTwitter

首页

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

资源链接

HackerNews API原版 HackerNewsNext.js

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

The Little Manual of API Design (2008) [pdf]

142 点作者 daviducolo将近 10 年前

6 条评论

fizixer将近 10 年前
I&#x27;ve been thinking about this at a meta level and I can&#x27;t get to reach any conclusion.<p>Think of a simple instruction: draw a line from (a,b) to (c,d).<p>How many ways can it be &quot;encoded as an API&quot;? we already have a gazillion forms of drawing: SVG, OpenGL, Postscript, Asymptote, PGF&#x2F;Tikz, Canvas, and so on. Why?<p>Forget about existing line-drawing APIs. Which of these would you choose?<p>- line(a,b,c,d)<p>- Line (a,b) to (c,d)<p>- draw-line (a,b) (c,d)<p>- drawline<p>- make-a-line<p>- line-from-to<p>- ...<p>- ...<p>Not to mention placement of parentheses (C vs s-expression), curly braces or angle bracket. The list goes on.<p>I started reading Bertrand Russell&#x27;s &#x27;On Denoting&#x27; but I&#x27;m not really sure it&#x27;ll help me out (although I haven&#x27;t finished reading it yet).<p>At another level: once you&#x27;ve converted your vector graphics primitive to &quot;pixel maps&quot;, that itself is no less of a language. So at a more fundamental level, it&#x27;s really information represenation, not language.<p>I&#x27;m not sure where the problem is, language vs computable-form vs information-representation.<p>Not to mention metalinguistics. Because API is not just one layer on top of your program. You build an API&#x2F;language layer as a scaffolding, to use it to build a higher level API&#x2F;language layer. And apparently its turtles all the way up and all the way down.<p>It&#x27;s all very confusing
评论 #9740383 未加载
评论 #9738046 未加载
评论 #9742011 未加载
评论 #9739243 未加载
评论 #9738128 未加载
评论 #9741509 未加载
trumpete将近 10 年前
&gt; Because HTML forces us to repeat the name of the tag in the close tag, it encourages us to write things like:<p><pre><code> the &lt;b&gt;goto &lt;u&gt;label&lt;&#x2F;b&gt;&lt;&#x2F;u&gt; statement </code></pre> What sort of demonic possession bullshit going on here? Who is &quot;encouraged&quot; to do such thing?
评论 #9738504 未加载
评论 #9738337 未加载
to3m将近 10 年前
Related to section 3.7: you should try to create as much builtin functionality as possible (ideally, all of it...) using the mechanism(s) provided for 3rd party extensions. This can give everybody confidence that the extension mechanism is useful and complete; if library source code is provided, it also provides a good stock of example extensions.
holgerp将近 10 年前
some good advice, some doubtful advice.<p>One advice in this pdf is that on designing first before implementing. I think iterative cycles of design &#x2F; implement &#x2F; use &#x2F; design &#x2F;implement use yield better results.
评论 #9737879 未加载
评论 #9740193 未加载
darylteo将近 10 年前
Seen some of these around... what I&#x27;ve been craving for is a little pdf of web api design.
omgitstom将近 10 年前
Something that I&#x27;ve found extremely valuable with API design for public facing APIs is use readme driven development. I think it complements a lot of the points brought up in the PDF .