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

科技回声

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

GitHubTwitter

首页

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

资源链接

HackerNews API原版 HackerNewsNext.js

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

Ask HN: What makes an API good?

67 点作者 relaunched超过 10 年前
I&#x27;ve consumed a great deal of major, public facing APIs over the years, some I&#x27;ve liked more than others. However, I&#x27;m writing a series of APIs for a new project, and ahead of starting I&#x27;ve documented the things I like about some APIs and things I don&#x27;t about others. For example, uri construction, documentation, response time, flexibility, code samples and organization of taxonomy help me differentiate good and bad.<p>I thought I&#x27;d ask, what do you think makes for a good api?

43 条评论

valarauca1超过 10 年前
1) URL construction: KISS (Keep It Simple Stupid), or as Einstein said, &quot;Everything should be made as simple as possible, but no simpler.&quot;<p>2) Documentation: Code examples, easy things like: &quot;This is what you send, this is what you get.&quot; &quot;If you change this, now you get this.&quot; Simple example heavy documentation. 1 example is worth a hundred lines of documentation.<p>3) Response Time: meh. If your at or around 100ms you don&#x27;t need to worry to much. If people want ~50+ calls per second, then ask them what their use case is, or have them pony up money. Then worry about response time.<p>4) Flexibility: Largely over rated. You can waste a ton of processing power trying to figure out what the user <i>meant</i> to say. Most of it is wasted, if their query doesn&#x27;t make sense return an error. Your performance will go up. This hooks into documentation, if your documentation is easy enough to understand you won&#x27;t have to fuzz the queries.<p>5) Code Samples: See documentation.
评论 #8521569 未加载
评论 #8521807 未加载
评论 #8521700 未加载
评论 #8521968 未加载
patio11超过 10 年前
First among all things: a good API allows developers to do something enormously useful within their applications which would be prohibitively difficult to do absent the API.<p>My two favorite APIs are, by a country mile, Twilio and Stripe. They have wonderful documentation, sane design choices, good first-party library support, responsive engineers on standby for questions, curl-able URLs which return human-parseable JSON, yadda yadda, but the most important reason they&#x27;re my favorite APIs is that they directly enable me to build and sell the things which feed my family.
notjosh超过 10 年前
Documentation is 1000x above anything else. This includes sample project(s).<p>Documentation is without question the deciding factor of whether I&#x27;ll use a service.<p>Besides that, I care about support channels, adherence to standards (i.e. correct HTTP status codes), and as few hoops as possible to jump through to start (i.e. a curl command to get my auth key, and away I go)
评论 #8521556 未加载
评论 #8522231 未加载
jasode超过 10 年前
1) Have the internal team use the same public API as much as possible. I believe Steve Yegge (of Google and Yahoo) wrote a long article about this concept. Here&#x27;s a link[1] but I can&#x27;t remember if it&#x27;s the definitive one I read before. By forcing your internal developers to use the same API, you see the frustrations of any incoherent designs that outsiders would see. Also, bug fixes fix the defects for private &amp; public users.<p>2) Design the API to encourage clients to stumble into the &quot;<i>pit of success.</i>&quot; I believe Microsoft&#x27;s .NET team originated this phrase.[2] This means sensible defaults for the the most common tasks. It leads to related maxims such as &quot;<i>make easy tasks easy and hard tasks possible.</i>&quot;<p>3) Additional documentation that&#x27;s organized thematically around &quot;tasks&quot;, &quot;workflow&quot;, &quot;usage scenarios&quot;, and &quot;concepts&quot;. It&#x27;s not enough just to have a dump of functions listed in alphabetical order presented as a &quot;reference guide&quot;. The reference guides are important but people unfamiliar with the new API need some handholding and reference guides don&#x27;t do that. The task-oriented documentation would be things like &quot;Getting Started&quot; or &quot;working demos&quot;.<p>[1]<a href="http:&#x2F;&#x2F;apievangelist.com&#x2F;2012&#x2F;01&#x2F;12&#x2F;the-secret-to-amazons-success-internal-apis&#x2F;" rel="nofollow">http:&#x2F;&#x2F;apievangelist.com&#x2F;2012&#x2F;01&#x2F;12&#x2F;the-secret-to-amazons-su...</a><p>[2]<a href="http:&#x2F;&#x2F;blogs.msdn.com&#x2F;b&#x2F;brada&#x2F;archive&#x2F;2003&#x2F;10&#x2F;02&#x2F;50420.aspx" rel="nofollow">http:&#x2F;&#x2F;blogs.msdn.com&#x2F;b&#x2F;brada&#x2F;archive&#x2F;2003&#x2F;10&#x2F;02&#x2F;50420.aspx</a>
massung超过 10 年前
Aside from common things like &quot;being useful&quot; the key aspects of a good API (to me) are:<p>1. Expose 2. Wrap 3. Consistency<p>Expose what&#x27;s going on under-the-hood. For example, an HTTP.Get function may do what&#x27;s needed 98% of the time, but if you don&#x27;t expose requests, sending, keep-alive, etc. then I won&#x27;t be able to do the last 2% when I really need it. Part of exposing is factoring your functions well.<p>Wrap what&#x27;s exposed to handle the most common cases. If I want to perform a GET request, I shouldn&#x27;t be required to create a request, open a socket, issue the request, parse the response, follow redirects, etc. There should just be a simple HTTP.Get function that does all that for me with the common options as arguments.<p>Finally, the API should be consistent. Consistency covers a range of topics. The API should be consistent within itself: consistent naming, modules, etc. It should be consistent within the environment (e.g. don&#x27;t use underscored function names in Go). But consistency also means future releases shouldn&#x27;t break existing code unless absolutely necessary.
mguterl超过 10 年前
You might want to check out The Little Manual of API Design:<p><a href="http:&#x2F;&#x2F;www4.in.tum.de&#x2F;~blanchet&#x2F;api-design.pdf" rel="nofollow">http:&#x2F;&#x2F;www4.in.tum.de&#x2F;~blanchet&#x2F;api-design.pdf</a>
评论 #8521511 未加载
angersock超过 10 年前
Some things that irk me:<p>0. JSON. Use JSON.<p>1. Version your API<p>2. Any numerical value whose precise value you care about, send as a string.<p>3. Any ID should be sent as a string.<p>4. Any timestamp should be sent as RFC3339 UTC.<p>5. Any data whose numerical value matters (i.e., must properly include NaNs, whatever) should be sent as an encoded base64 blob.<p>6. Properly support HEAD, PUT, PATCH, OPTIONS.<p>7. Send back your response as human-readable JSON, with newlines and tabs. If you can&#x27;t afford the bandwidth (protip: you <i>can</i>), then you shouldn&#x27;t be using a text format anyways.<p>8. Allow me to change replies using accept headers <i>and</i> extensions on the URI. Document the order of precedence.<p>9. Understand the limits of the REST mental model for handling things--don&#x27;t be afraid to have a <i>few</i> &quot;ugly&quot; endpoints.
jordanpg超过 10 年前
One vote for <i>good</i> documentation.<p>Not just a link to the Javadocs; preferably a &quot;getting started&quot; page that covers the most common use cases with plenty of plug and play examples (if such a thing is even possible in your case).<p>Also, getting back to the API reference, I&#x27;m grateful when there is a roadmap or overview of the class&#x2F;package structure so I don&#x27;t have to crawl through the entire thing.
评论 #8521587 未加载
评论 #8521698 未加载
jedisct1超过 10 年前
Client libraries.<p>Release and support good client libraries for popular programming languages.<p>This is way more important than documenting your API at all.<p>Nobody likes having to read the gory details of how your API works and having to write a HTTP client around it. And everytime they do, error handling is badly handled, if at all.<p>People want to start using your service right away. They want to just call one function to do a thing, without having to worry about how it works underneath.<p>Even if this is not HTTP, think about MySQL. Used everywhere, via tons of different programming languages. Yet virtually no one knows how the protocol (&quot;API&quot;) works. And this is completely fine.<p>Having good client libraries also allows updating the protocol without requiring users to change their apps.
grosskur超过 10 年前
The Heroku platform team has a good document about their API design guidelines:<p><a href="https:&#x2F;&#x2F;github.com&#x2F;interagent&#x2F;http-api-design" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;interagent&#x2F;http-api-design</a>
评论 #8521900 未加载
adelevie超过 10 年前
At 18F (a digital services consultancy within the US federal government), we&#x27;ve drafted API Standards[1]. They&#x27;re a set of recommendations, rebuttable presumptions, and bright line rules that we expect our APIs to adhere to. For an organization that may offer several APIs, having a set of standards will help ensure, among other things, baseline quality and consistency.<p>[1] <a href="https:&#x2F;&#x2F;github.com&#x2F;18f&#x2F;api-standards" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;18f&#x2F;api-standards</a>
mockindignant超过 10 年前
I highly recommend this ~hour long talk given by Josh Bloch a few years ago, it is quite good and gives plenty of concrete examples: <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=aAb7hSCtvGw" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=aAb7hSCtvGw</a>
评论 #8521513 未加载
paulkoer超过 10 年前
I highly recommend the following talk by Joshua Bloch: &quot;How to design a good API and why it mattes&quot; [1].<p>Key points:<p>- When in doubt, leave it out - you can never remove things from an API but always add to it.<p>- Write several clients of the API to get a good feel how its used. Three is usually enough, one is not.<p>[1] <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=aAb7hSCtvGw" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=aAb7hSCtvGw</a>
oneeyedpigeon超过 10 年前
My two pet peeves are authentication and rate limiting.<p>Authentication - unless you&#x27;re dealing with uber-sensitive details, make authentication as straightforward as possible. HTTP basic over SSL works fine for me. Bonus points for authentication-free calls for all your public data that doesn&#x27;t need to be hidden. If you absolutely must use OAuth, please make sure you implement it to the standard, and - ideally - give me a robust client library in my language of choice.<p>Rate limiting - ideally, don&#x27;t. Obviously, this depends on your audience - I understand why twitter need to rate-limit. Otherwise, be as nice to me as possible, let me &#x27;save up&#x27; calls over time if you can handle the traffic, and provide me with lots of information about what my limit is, when it will be reset, etc.
评论 #8521747 未加载
richbradshaw超过 10 年前
Consistency, predictability, documentation, reliable sample client in a couple of popular languages (e.g. PHP, Python, Ruby), well abstracted.
calpaterson超过 10 年前
The main thing about creating a good API is that you have a good relationship and good communication with the consumers of that API. I&#x27;ve seen a lot of people making internal APIs inside companies treat it as another way to throw something over a wall.<p>There&#x27;s very little universal about a &quot;good&quot; API design. Even response time might not matter if your users aren&#x27;t using it synchronously. Best way to make an API is to have a plan to support old versions, release something early, see what people make of it and incorporate their improvements. Worst way to make an API is to try and think of everything before you start - you will fail and you&#x27;ll take a long time
评论 #8521574 未加载
logicuce超过 10 年前
Assuming you take care of the essentials like documentation and code samples, following will make your API shine.<p>* Explanatory Error Responses: Tell what was wrong in a problematic request and, potentially, how to fix the request<p>* Introspection end points: Which can tell you more about the request (headers&#x2F;body) and credentials (rate limits, app id, etc) observed by the server. Is very handy in case of debugging.<p>* API should be able to tell properly when its unavailable. Ideally by returning proper HTTP 503 response.
sergiosgc超过 10 年前
1. Documentation. It has been said in other comments. If you do nothing else right, do documentation. It is paramount. Documentation must contain code samples that can be ran without scaffolding a huge project. cURL command lines -- or the equivalent in non-HTTP APIs, are, for me, as good as it gets.<p>2. Account for failure. The failure path is more important than the-one-true-path. Be verbose in your errors. Be specific in your error descriptions. Be extensive in the kinds of error conditions you test, particularly when validating the input. Bonus points here if you can make the API introspectable.<p>3. Resource oriented. Expose your resources, then verbs on top of that. These are application-level resources. Do not directly expose the data model. RESTful APIs obviously follow this, but going REST is not the only option.<p>4. Stateless, or with as little state as possible. Stateless APIs make clients <i>a lot</i> simpler. They have the added bonus of scaling better on your end (on the server end).<p>5. Predictable. This is achieved by being both consistent and verbose. Do not use abbreviations on method names. Define a vocabulary and use always the same nouns to refer to the same entities. If using positional arguments, use the same calling order (i.e. avoid the needle&#x2F;haystack you see in PHP).
评论 #8522093 未加载
fosrias超过 10 年前
Well said by many above. Would phrase some thoughts as follows:<p>1. Developer Experience (DX) - How quickly can a developer get up and running trying the API (ideally immediately). - Client code generation. - How understandable is the API? Does it use common vocabulary or terms you have to think about what they mean?<p>2. Accuracy of documentation - API and docs in sync. - Ease of locating items in the documentation.<p>3. Debugabbility - How easy is it to figure out why requests fail. - How easy is it to test edge cases for success&#x2F;failure and experiment.<p>4. Consumer participation in design&#x2F;prototyping design tools - Mocking functionality. - Collaboration in design that is immediately possible to test. - Making it easy to get feedback on different design options.<p>In the end of the day, good design makes for a good API. And, being able to involve a variety of stakeholders in the design process in a human-friendly way is really important to achieve that goal.<p>As a contributor to ApiBlueprint [1], we have been working to develop a suite of tools to help all this. I include a link to a sample api blueprint [2] and to the public documentation&#x2F;DX portal you get if you import it and render documentation for it in apiary.io [3].<p>[1] <a href="http:&#x2F;&#x2F;apiblueprint.org&#x2F;" rel="nofollow">http:&#x2F;&#x2F;apiblueprint.org&#x2F;</a> [2] <a href="https:&#x2F;&#x2F;gist.github.com&#x2F;fosrias&#x2F;6377469bf0e1d2fd10c7" rel="nofollow">https:&#x2F;&#x2F;gist.github.com&#x2F;fosrias&#x2F;6377469bf0e1d2fd10c7</a> [3] <a href="http:&#x2F;&#x2F;docs.sampleapi42.apiary.io&#x2F;" rel="nofollow">http:&#x2F;&#x2F;docs.sampleapi42.apiary.io&#x2F;</a>
mmmbeer超过 10 年前
If its a Java or object-oriented framework or library - follow SOLID principals and limit dependencies. Make it unit testable. Try to make it consistent - calls to get one type of object should be similar to ways to get other types of data, etc. Functional approach to the interfaces - pass in required arguments, get back result. Don&#x27;t require user&#x2F;developer to create several configuration or factory objects before they can call a simple method to get some data, etc. Don&#x27;t require the use of dependency injection frameworks or other complexities. If its web-based API return data as simple JSON or XML without overly complex namespaces, etc. Name things consistently - the names of response objects and properties should be the same as the corresponding inputs, etc. Copy - look at a successful API or library which does something similar - then copy the way it works and the way its documented. Especially if the users&#x2F;developers already know how to use that one...
ripberge超过 10 年前
I think it depends upon the use cases of the API, but if you want someone to be able to build snappy and fast &quot;apps&quot; using your API rather than just facilitating movement of data in&#x2F;out for an integration with another piece of software, I think granularity is important.<p>Having built our front end using AngularJS, we are the first users of our own API and that has driven it&#x27;s design. In order to make things quick, we really needed to trim down response payloads in some cases which kind of deviates from standard CRUD patterns in some areas.<p>This has come at the expense of good documentation (we have a lot more methods now and having good examples of all of them will be expensive) and consistency--things are not very uniform anymore. However, as an API consumer I&#x27;d rather have the API give me too many options rather than too little. Our API has gone from &quot;pretty&quot; to &quot;very functional&quot;.
评论 #8521932 未加载
jgrodziski超过 10 年前
There was an excellent talk at the last QCon New-York conference about good API design: <a href="http:&#x2F;&#x2F;www.infoq.com&#x2F;presentations&#x2F;API-design-mistakes" rel="nofollow">http:&#x2F;&#x2F;www.infoq.com&#x2F;presentations&#x2F;API-design-mistakes</a> Worth watch it in my opinion :-)
lsjroberts超过 10 年前
Phil Sturgeon&#x27;s &quot;Build APIs You Won&#x27;t Hate&quot; is a fantastic resource. It is directed towards PHP but the ideas are obviously transferable.<p><a href="https:&#x2F;&#x2F;leanpub.com&#x2F;build-apis-you-wont-hate" rel="nofollow">https:&#x2F;&#x2F;leanpub.com&#x2F;build-apis-you-wont-hate</a>
vmarsy超过 10 年前
You can find these slides interesting:<p><a href="http:&#x2F;&#x2F;slideshare.net&#x2F;guestbe92f4&#x2F;how-to-design-a-good-a-p-i-and-why-it-matters-g-o-o-g-l-e" rel="nofollow">http:&#x2F;&#x2F;slideshare.net&#x2F;guestbe92f4&#x2F;how-to-design-a-good-a-p-i...</a>
bpedro超过 10 年前
I know what makes it bad: <a href="http:&#x2F;&#x2F;nordicapis.com&#x2F;5-reasons-why-developers-are-not-using-your-api&#x2F;" rel="nofollow">http:&#x2F;&#x2F;nordicapis.com&#x2F;5-reasons-why-developers-are-not-using...</a>
onaclov2000超过 10 年前
The ability to use&#x2F;see the api in action in the page (like maybe a click here button to see it work), so you can do things like see the network traffic so you can see what works without having to worry about things like CORS or whatnot. (my .02)<p>Also a way to use the api without needing to expose keys, I primarily try to consume API&#x27;s using angularJS which is client side only, so giving out my key can be a problematic experience.<p>Thus most of my apps I write are for myself, and not others, since this is very rarely considered.
rfclark超过 10 年前
If that data is ever to be viewed by a human you should focus on presenting the data in such a way that it is as easy as possible to display on the screen, if the process of getting the data to the screen is not easy the vast majority will either try to find an easier product to work with or just give up on trying to find a solution to that problem. (IT guys have a lot on their plate, and mountain of forgotten projects because they didn&#x27;t have the time)
kevinSuttle超过 10 年前
Agreed with all the previous comments.<p>URL Design is key. I often refer to the naming chapter of Uncle Bob&#x27;s Clean Code book for this. This also helps with consistency and predictability, which in turn, makes writing docs easier.<p>I&#x27;ve got an API Design Readlist, which I&#x27;ve added this thread to. <a href="http:&#x2F;&#x2F;readlists.com&#x2F;6c5c6009&#x2F;" rel="nofollow">http:&#x2F;&#x2F;readlists.com&#x2F;6c5c6009&#x2F;</a>
davidkellis超过 10 年前
Ease of use. It should be easy to use. Someone else commented that simple is what makes an API good. To the extent that a simple API is easy to use, I agree.<p>I think an API is no different from any other software product. People like software that is easy to use. I think an API should be easy to use too. To me, that&#x27;s what makes an API good.
thom超过 10 年前
I like it when APIs offer good filtering options for searches. When all you have is basically &quot;here is a list of things&quot; + &quot;here is a single thing with an ID&quot;, all you end up doing is scraping the entire list to do fun things.
wging超过 10 年前
Simplicity. As a consumer of your API I should not have to do anything I don&#x27;t need to. The worst thing is when you have to jump through hoops to deal with an API that was clearly designed for the implementer&#x27;s convenience, not yours.
wheels超过 10 年前
This superficially is about C++, but in practice it&#x27;s a collection of good advice for APIs in general:<p><a href="http:&#x2F;&#x2F;doc.qt.digia.com&#x2F;qq&#x2F;qq13-apis.html" rel="nofollow">http:&#x2F;&#x2F;doc.qt.digia.com&#x2F;qq&#x2F;qq13-apis.html</a>
dbarlett超过 10 年前
I agree with most of Vinay Sahni&#x27;s points: <a href="http:&#x2F;&#x2F;www.vinaysahni.com&#x2F;best-practices-for-a-pragmatic-restful-api" rel="nofollow">http:&#x2F;&#x2F;www.vinaysahni.com&#x2F;best-practices-for-a-pragmatic-res...</a>
tomp超过 10 年前
Versioning. Also, make sure that you&#x27;re committed to supporting old versions of your API for the foreseeable future (the actual time period depends on the company - for Google, 20-30 years, while 3-5 years for a startup).
jeff_cressman超过 10 年前
Would be great if you shared what you&#x27;ve compiled as well. Thanks.
Flenser超过 10 年前
You may find some of these helpful:<p>• Web API Design Crafting Interfaces that Developers Love - eBook [APIGEE]<p>• How to design an API function that creates something [SHAREDOM] [SHAREDOM-HN]<p>• Microservices and the First Law of Distributed Objects [FOWLER] [FOWLER-HN]<p>• Lego’s API Strategy: Resourcing Developers and Building a Business Case [LEGO]<p>• A review of all most common API editors — Medium [ORLIESAURUS] [ORLIESAURUS-HN]<p>• Best Practices for Designing a Pragmatic RESTful API [VINAYSAHNI] [VINAYSAHNI-HN1] [VINAYSAHNI-HN2]<p>• Best practices for API versioning? - Stack Overflow [SO] [SO-HN]<p>• Designing Hypermedia APIs [KLABNIK]<p>[APIGEE] <a href="https:&#x2F;&#x2F;pages.apigee.com&#x2F;web-api-design-ebook.html" rel="nofollow">https:&#x2F;&#x2F;pages.apigee.com&#x2F;web-api-design-ebook.html</a><p>[SHAREDOM] <a href="http:&#x2F;&#x2F;sheredom.wordpress.com&#x2F;2014&#x2F;08&#x2F;10&#x2F;how-to-design-api-function-that-creates-something&#x2F;" rel="nofollow">http:&#x2F;&#x2F;sheredom.wordpress.com&#x2F;2014&#x2F;08&#x2F;10&#x2F;how-to-design-api-f...</a><p>[SHAREDOM-HN] <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=8160071" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=8160071</a><p>[FOWLER] <a href="http:&#x2F;&#x2F;martinfowler.com&#x2F;articles&#x2F;distributed-objects-microservices.html" rel="nofollow">http:&#x2F;&#x2F;martinfowler.com&#x2F;articles&#x2F;distributed-objects-microse...</a><p>[FOWLER-HN] <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=8172980" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=8172980</a><p>[LEGO] <a href="http:&#x2F;&#x2F;nordicapis.com&#x2F;legos-api-strategy-resourcing-developers-building-business-case&#x2F;" rel="nofollow">http:&#x2F;&#x2F;nordicapis.com&#x2F;legos-api-strategy-resourcing-develope...</a><p>[ORLIESAURUS] <a href="https:&#x2F;&#x2F;medium.com&#x2F;@orliesaurus&#x2F;a-review-of-all-most-common-api-editors-6a720dc4f4e6" rel="nofollow">https:&#x2F;&#x2F;medium.com&#x2F;@orliesaurus&#x2F;a-review-of-all-most-common-...</a><p>[ORLIESAURUS-HN] <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=8505244" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=8505244</a><p>[SO] <a href="http:&#x2F;&#x2F;stackoverflow.com&#x2F;a&#x2F;398564&#x2F;2541" rel="nofollow">http:&#x2F;&#x2F;stackoverflow.com&#x2F;a&#x2F;398564&#x2F;2541</a><p>[SO-HN] <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=7350432" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=7350432</a><p>[VINAYSAHNI] <a href="http:&#x2F;&#x2F;www.vinaysahni.com&#x2F;best-practices-for-a-pragmatic-restful-api" rel="nofollow">http:&#x2F;&#x2F;www.vinaysahni.com&#x2F;best-practices-for-a-pragmatic-res...</a><p>[VINAYSAHNI-HN1] <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=6624229" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=6624229</a><p>[VINAYSAHNI-HN2] <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=5819231" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=5819231</a><p>[KLABNIK] <a href="http:&#x2F;&#x2F;www.designinghypermediaapis.com&#x2F;blog&#x2F;index.html" rel="nofollow">http:&#x2F;&#x2F;www.designinghypermediaapis.com&#x2F;blog&#x2F;index.html</a>
3beard超过 10 年前
Thread safety. If you write an API never forget that people may want to use it in more than one thread.
zoner超过 10 年前
Documentation.
metaphorm超过 10 年前
Consistency. pick a convention and keep doing things that way, always and everywhere.
bvanvugt超过 10 年前
Agree with notjosh on this -- so what makes documentation good?
评论 #8522282 未加载
jmakuc超过 10 年前
Be strict with your output and promiscuous with your input.
robertlmullen74超过 10 年前
The simplest API that could possibly work.
CmonDev超过 10 年前
NuGet availability is a strong win.