Mastouille

Miguel Afonso Caetano"API documentation writers don’t just write content. We’re liaisons between client developers and in-house developers. I often say “we’re paid by the company but work for our clients.” Many think that in-house developers automatically empathize with the client developers. After all, they’re all developers, right? Right? Well, no. A surprising number of times, in-house developers are actually out of touch with clients. Why else would we be talking about having clear field names? They get tunnel vision or become myopic while in the code. This is not unique to developers. All professions have this risk. That’s our job to make sure that clarity is there for the clients. We can’t do it completely by ourselves. We need developer’s buy in. That means, one of two things.We can push back on the in-house developers. When we see a meaningless, poor, or bad field names, for example, we have the right, if not obligation, to get it changed. Some developers may disagree. That’s OK. The truth is, the code doesn’t belong exclusively to in-house developers. It’s the client’s code. They’re the ones intended to run the code, to know which fields to pass in, with which values, and to read the response JSON. That makes it our code, too. We not only have to run the code but also to explain this to clients. We have a say in the matter."<a href="https://robertdelwood.medium.com/writing-for-humans-an-api-documentation-writer-writes-3c51a6ea87a5" rel="nofollow noopener noreferrer" translate="no" target="_blank">https://robertdelwood.medium.com/writing-for-humans-an-api-documentation-writer-writes-3c51a6ea87a5</a><a href="https://tldr.nettime.org/tags/TechnicalWriting" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#TechnicalWriting</a> <a href="https://tldr.nettime.org/tags/APIs" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#APIs</a> <a href="https://tldr.nettime.org/tags/API" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#API</a> <a href="https://tldr.nettime.org/tags/APIDocumentation" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#APIDocumentation</a> <a href="https://tldr.nettime.org/tags/SoftwareDevelopment" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#SoftwareDevelopment</a> <a href="https://tldr.nettime.org/tags/APIs" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#APIs</a> <a href="https://tldr.nettime.org/tags/TechnicalCommunication" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#TechnicalCommunication</a>

Miguel Afonso Caetano"The accompanying diagram is intended to help you quickly decide how to document an API, but particularly a REST API. The first split is just to make sure you are looking for the right kind of API.Here is some more context to help you decide on an approach and get started."<a href="https://gist.github.com/briandominick/3ffab6be460fbde799aa34e0a42a4299" rel="nofollow noopener noreferrer" translate="no" target="_blank">https://gist.github.com/briandominick/3ffab6be460fbde799aa34e0a42a4299</a><a href="https://tldr.nettime.org/tags/API" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#API</a> <a href="https://tldr.nettime.org/tags/APIs" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#APIs</a> <a href="https://tldr.nettime.org/tags/APIDesign" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#APIDesign</a> <a href="https://tldr.nettime.org/tags/REST" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#REST</a> <a href="https://tldr.nettime.org/tags/APIDocumentation" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#APIDocumentation</a> <a href="https://tldr.nettime.org/tags/OpenAPI" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#OpenAPI</a> <a href="https://tldr.nettime.org/tags/DocsAsCode" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#DocsAsCode</a> <a href="https://tldr.nettime.org/tags/TechnicalWriting" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#TechnicalWriting</a> <a href="https://tldr.nettime.org/tags/TechnicalCommunication" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#TechnicalCommunication</a>

Miguel Afonso Caetano"Getting to this point isn’t unusual. Clients clearly think they’re making the call correctly, or else they would fix the endpoint themselves. Some misspellings are difficult to catch. The enum USER_RETREIVE may not be noticed from USER_RETRIEVE, especially if picking it from a list. Misspellings happen and they’re not always caught before making it to the contract. As an aside, that’s why it’s important writers routinely check development’s changes. This applies, too, to our testing calls in Postman, where manually entering endpoints and values are more pervasive.The reason this isn’t caught is simple: We’re not expecting it.For our testing, the call is made and we get results. We may even spot check some of them. But generally, results aren’t examined that closely. For instance, how often do you so carefully examine a returned list of 50 or 100 items? You check may check that the objects are complete but not that the list conforms to the search criteria.The reason this happens is because of an intentional behavior on the server. This behavior is called Lenient Handling or Strict Handling."<a href="https://robertdelwood.medium.com/understanding-query-parameter-handling-in-rest-calls-1821e0c3fa8c" rel="nofollow noopener noreferrer" translate="no" target="_blank">https://robertdelwood.medium.com/understanding-query-parameter-handling-in-rest-calls-1821e0c3fa8c</a><a href="https://tldr.nettime.org/tags/APIs" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#APIs</a> <a href="https://tldr.nettime.org/tags/RESTAPIs" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#RESTAPIs</a> <a href="https://tldr.nettime.org/tags/Rest" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Rest</a> <a href="https://tldr.nettime.org/tags/APITesting" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#APITesting</a> <a href="https://tldr.nettime.org/tags/APIDesign" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#APIDesign</a> <a href="https://tldr.nettime.org/tags/APIDocumentation" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#APIDocumentation</a> <a href="https://tldr.nettime.org/tags/SoftwareDevelopment" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#SoftwareDevelopment</a>

Miguel Afonso Caetano“A README acts as the front door to an API, offering consumers brief and sufficient information to get started. A full documentation is a place where consumers go to when they need to find information about any detail of the API. Having one doesn't mean you shouldn't have the other. But, having a README is, in my opinion, the very minimum you can do if you're serious about your API. And, at the very minimum, there are three elements I'd consider.”<a href="https://tldr.nettime.org/tags/APIs" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#APIs</a> <a href="https://tldr.nettime.org/tags/APIDocumentation" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#APIDocumentation</a> <a href="https://tldr.nettime.org/tags/Markdown" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Markdown</a> <a href="https://tldr.nettime.org/tags/TechnicalWriting" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#TechnicalWriting</a> <a href="https://tldr.nettime.org/tags/Git" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Git</a> <a href="https://tldr.nettime.org/tags/DocsAsCode" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#DocsAsCode</a> <a href="https://apichangelog.substack.com/p/three-elements-of-a-good-api-readme" rel="nofollow noopener noreferrer" translate="no" target="_blank">https://apichangelog.substack.com/p/three-elements-of-a-good-api-readme</a>

Miguel Afonso Caetano"A quick start guide offers concise step-by-step instructions to help users quickly get started with a product, service, or tool. In the context of API documentation, a quick start guide covers the minimal steps required for developers to make their first API call successfully. It typically provides steps such as how to create an account, where to locate API keys or credentials, how to authenticate, example code to make a basic API call, a way to display the response, and troubleshooting tips. The goal is to deliver a quick win to developers and provide a foundation to integrate with your API."<a href="https://www.apimatic.io/blog/how-to-design-a-quick-start-guide-for-your-api" rel="nofollow noopener noreferrer" translate="no" target="_blank">https://www.apimatic.io/blog/how-to-design-a-quick-start-guide-for-your-api</a><a href="https://tldr.nettime.org/tags/TechnicalWriting" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#TechnicalWriting</a> <a href="https://tldr.nettime.org/tags/APIs" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#APIs</a> <a href="https://tldr.nettime.org/tags/APIDocumentation" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#APIDocumentation</a> <a href="https://tldr.nettime.org/tags/SoftwareDocumentation" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#SoftwareDocumentation</a> <a href="https://tldr.nettime.org/tags/GettingStarted" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#GettingStarted</a> <a href="https://tldr.nettime.org/tags/Tutorials" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Tutorials</a> <a href="https://tldr.nettime.org/tags/SoftwareDevelopment" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#SoftwareDevelopment</a> <a href="https://tldr.nettime.org/tags/DE" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#DE</a> <a href="https://tldr.nettime.org/tags/DeveloperExperience" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#DeveloperExperience</a>

Miguel Afonso Caetano"Normally, you don't visit your own API documentation that often, right? I mean, if you already know how your API works, why would you want to consult its documentation? Conversely, there's a place you visit—or should visit—very often, with information you care about your API. I assume you have an API dashboard where you can review metrics such as the ones I described earlier. Usually, the dashboard lives close to the API gateway, or somewhere where other company-wide observability tools reside. What I'm proposing here, in short, is that the API documentation can be the best place to present those metrics to you, the producer.Being able to see the metrics you care about right near the documentation for each part of your API feels refreshing. You could, for instance, be looking at the reference of one operation and immediately see its usage trend, the error rate, the number of active consumers in the last hour, and so on. What's more, some of the information visible only to you could also be actionable. You could, for instance, open the pending support requests to see what the top complaints are. Or, you could immediately check why there's such a percentage of errors on one single operation.While most information would be restricted to you, the producer, I argue that some things could even be openly shared with your API consumers. Imagine being a consumer and seeing a list of "popular" API operations right on the documentation. Or understanding if a certain operation is producing a high error rate. All these things could be easily available in the API documentation."<a href="https://apichangelog.substack.com/p/producer-oriented-api-documentation" rel="nofollow noopener noreferrer" translate="no" target="_blank">https://apichangelog.substack.com/p/producer-oriented-api-documentation</a><a href="https://tldr.nettime.org/tags/TechnicalWriting" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#TechnicalWriting</a> <a href="https://tldr.nettime.org/tags/APIs" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#APIs</a> <a href="https://tldr.nettime.org/tags/APIDocumentation" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#APIDocumentation</a> <a href="https://tldr.nettime.org/tags/SoftwareDocumentation" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#SoftwareDocumentation</a> <a href="https://tldr.nettime.org/tags/APIMetrics" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#APIMetrics</a> <a href="https://tldr.nettime.org/tags/APIAnalytics" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#APIAnalytics</a> <a href="https://tldr.nettime.org/tags/SoftwareDevelopment" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#SoftwareDevelopment</a>

Miguel Afonso Caetano"The quality of job descriptions varies wildly. That means how the job is described, the components of the job, and expertise expected for each component. The descriptions are better for the common job types, such as project and product managers, developers, and sales. Companies know what those are and have experience hiring those.All that falls apart when it comes to writing, of any type, and specifically API documentation writers. CEOs, who I love to vilify for this reason, generally don’t understand technical writing and technical writers. To them, and that attitude often trickles down the table of organization, see copy, marketing, content, and technical writing as the same and interchangeable. I believe this causes the low pay rates, because we’re seen as a commodity, going at market rate. A doctor with 15 years of experience is treated as an expert. A writer with 15 years of experience competes in the marketplace with junior writers. A shame for sure. I digress some but that needed to be pointed out.There is information to be mined from bad job descriptions, if you know what to look for and know how to use that information."<a href="https://robertdelwood.medium.com/reading-api-documentation-writers-job-descriptions-92124e5d9008" rel="nofollow noopener noreferrer" translate="no" target="_blank">https://robertdelwood.medium.com/reading-api-documentation-writers-job-descriptions-92124e5d9008</a><a href="https://tldr.nettime.org/tags/TechnicalWriting" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#TechnicalWriting</a> <a href="https://tldr.nettime.org/tags/APIDocumentation" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#APIDocumentation</a> <a href="https://tldr.nettime.org/tags/APIs" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#APIs</a> <a href="https://tldr.nettime.org/tags/SoftwareDocumentation" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#SoftwareDocumentation</a> <a href="https://tldr.nettime.org/tags/SoftwareDevelopment" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#SoftwareDevelopment</a>

Miguel Afonso Caetano"In short, APIs are how businesses speak to one another. Breaking this oath with a poor integration experience is a surefire way to reduce your business potential. By utilizing a source of truth and baking a specification-first approach into your API development and documentation practices, you more clearly communicate changes, reducing the possibility of broken clients and promoting forward compatibility. Great API products must be well-described, easy to understand, and predictable in the long run.In the end, the business effects of specification-driven development are manifold. Whether you're building RESTful, GraphQL, or event-driven partner services, having reliable API documentation is important to compete in the digital economy. This consistency equates to a better partner experience, leading to stickier partners and less customer churn. By enabling smoother integrations and reducing frustration, spec-first documentation directly contributes to partner retention and loyalty, which ultimately drives revenue growth."<a href="https://bump.sh/blog/how-spec-first-api-documentation-aids-partner-integration" rel="nofollow noopener noreferrer" translate="no" target="_blank">https://bump.sh/blog/how-spec-first-api-documentation-aids-partner-integration</a><a href="https://tldr.nettime.org/tags/APIs" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#APIs</a> <a href="https://tldr.nettime.org/tags/APIDocumentation" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#APIDocumentation</a> <a href="https://tldr.nettime.org/tags/TechnicalWriting" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#TechnicalWriting</a> <a href="https://tldr.nettime.org/tags/SpecFirst" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#SpecFirst</a> <a href="https://tldr.nettime.org/tags/SoftwareDocumentation" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#SoftwareDocumentation</a> <a href="https://tldr.nettime.org/tags/Docs" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Docs</a> <a href="https://tldr.nettime.org/tags/DeveloperExperience" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#DeveloperExperience</a> <a href="https://tldr.nettime.org/tags/DocsAsCode" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#DocsAsCode</a>

Miguel Afonso Caetano"So, if developers aren’t going to use Try Its, what harm is there for including them? They can just ignore them, right? Perhaps, but there’s more to it.It takes up valuable screen real estate (the right corner above the fold). Writers need to optimize the developer experience, even to the point of minimizing eye movements. Make it easy to find details. That space could be used more productively.We “should know” but we don’t. This segues into the real reason. It demonstrates that writers don’t know the developer experience. Let’s be blunt. We’re delivering documentation suites that have not been tested properly, calls that are unlikely to have been tested, and tools developers don’t use. Not understanding these issues is the fundamental reason writers also need developer experience. Writers simply can’t empathize with own audiences, which means we supplying developers with inadequate and incomplete tools and documentation. This is a real concern.This is not a condemnation. Quite the opposite. API documentation writers need to empathize with developers. Writers do this by treating this as a craft, learn a little about development each day, and move slowly along the experience spectrum towards the developer’s end. Learn a language. It doesn’t matter which one. Java, JavaScript, to DOS batch commands, UNIX command line programming, Word macros, Python, or even AutoHotKey*. All of these have programming concepts and that’s what matters. Learn about them, which requires using an API guide, craft statements, and debug them is at the heart of the matter."<a href="https://robertdelwood.medium.com/why-i-dont-like-try-it-f44112ed1b6d" rel="nofollow noopener noreferrer" translate="no" target="_blank">https://robertdelwood.medium.com/why-i-dont-like-try-it-f44112ed1b6d</a><a href="https://tldr.nettime.org/tags/APIs" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#APIs</a> <a href="https://tldr.nettime.org/tags/APIDocumentation" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#APIDocumentation</a> <a href="https://tldr.nettime.org/tags/SoftwareDevelopment" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#SoftwareDevelopment</a> <a href="https://tldr.nettime.org/tags/TechnicalWriting" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#TechnicalWriting</a>

Phil Sturgeon💻 This was an absolute beast to write, a complete guide to OpenAPI v3.1!Use this guide instead of the Swagger.io guide which was stuck on OpenAPI v3.0, and instead of trying to wrap your brain around the specification which isn’t intended to be user documentation. <a href="https://mastodon.green/tags/OpenAPI" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#OpenAPI</a> <a href="https://mastodon.green/tags/APIDevelopment" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#APIDevelopment</a> <a href="https://mastodon.green/tags/apidesign" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#apidesign</a> <a href="https://mastodon.green/tags/APIDocumentation" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#APIDocumentation</a> <a href="https://docs.bump.sh/guides/openapi/specification/v3.1/introduction/what-is-openapi/" rel="nofollow noopener noreferrer" translate="no" target="_blank">https://docs.bump.sh/guides/openapi/specification/v3.1/introduction/what-is-openapi/</a>

:mastodon: Mike AmundsenThe Use of Symbology in API Documentation<a href="https://apichangelog.substack.com/p/the-use-of-symbology-in-api-documentation" rel="nofollow noopener noreferrer" translate="no" target="_blank">https://apichangelog.substack.com/p/the-use-of-symbology-in-api-documentation</a>"Everything is a symbol. Every symbol is a message. How can API documentation benefit from the use of symbols?" -- <a href="https://mastodon.social/tags/BrunoPedro" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#BrunoPedro</a><a href="https://mastodon.social/tags/api360" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#api360</a> <a href="https://mastodon.social/tags/apiDocumentation" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#apiDocumentation</a> <a href="https://mastodon.social/tags/apiChangelog" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#apiChangelog</a>

:mastodon: Mike AmundsenHow to Document Event-Driven API Message Payloads<a href="https://apichangelog.substack.com/p/how-to-document-event-driven-api" rel="nofollow noopener noreferrer" translate="no" target="_blank">https://apichangelog.substack.com/p/how-to-document-event-driven-api</a>"The REST mindset doesn't apply to event-driven design. And then you have to define the messages that subscribers will consume. What are the tools and processes that can help you?" -- <a href="https://mastodon.social/tags/BRUNO_PEDRO" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#BRUNO_PEDRO</a><a href="https://mastodon.social/tags/api360" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#api360</a> <a href="https://mastodon.social/tags/eventDriven" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#eventDriven</a> <a href="https://mastodon.social/tags/apiDocumentation" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#apiDocumentation</a>

Phil Sturgeon🎙️🚨 API Podcast Alert! 🚨Learn all about Redocly the handy OpenAPI documentation tool with a Swiss army CLI that does everything (even linting!), and a bit more about the plan for OpenAPI v4 (a.k.a Moonwalk). Good natter in general with <a href="https://indieweb.social/@lornajane" class="u-url mention" rel="nofollow noopener noreferrer" target="_blank">@lornajane</a> who I always love catching up with. <a href="https://mastodon.green/tags/APIDesign" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#APIDesign</a> <a href="https://mastodon.green/tags/APIDevelopment" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#APIDevelopment</a> <a href="https://mastodon.green/tags/apidocumentation" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#apidocumentation</a> <a href="https://apisyouwonthate.com/podcast/redocly-openapi-moonwalk-lorna-jane-mitchell/" rel="nofollow noopener noreferrer" translate="no" target="_blank">https://apisyouwonthate.com/podcast/redocly-openapi-moonwalk-lorna-jane-mitchell/</a>

:mastodon: Mike AmundsenWriting REST and OpenAPI documentation for a broad audience<a href="https://tedspence.com/writing-rest-and-openapi-documentation-for-a-broad-audience-72f35cbc1b89" rel="nofollow noopener noreferrer" translate="no" target="_blank">https://tedspence.com/writing-rest-and-openapi-documentation-for-a-broad-audience-72f35cbc1b89</a>"One author’s theory of how to write usable documentation without going crazy" -- <a href="https://mastodon.social/tags/TedSpence" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#TedSpence</a><a href="https://mastodon.social/tags/api360" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#api360</a> <a href="https://mastodon.social/tags/apiDocumentation" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#apiDocumentation</a> <a href="https://mastodon.social/tags/openAPI" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#openAPI</a>

:mastodon: Mike AmundsenTips for better documentation with OpenAPI<a href="https://lornajane.net/posts/2023/tips-for-better-documentation-with-openapi" rel="nofollow noopener noreferrer" translate="no" target="_blank">https://lornajane.net/posts/2023/tips-for-better-documentation-with-openapi</a>"Between hanging out in the Write the Docs community, and recently being at the APItheDocs conference, I’ve answered a bunch of questions about getting good documentation from an OpenAPI document, so I thought I’d round them up in case it’s useful." -- <a href="https://mastodon.social/tags/LornaJane" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#LornaJane</a><a href="https://mastodon.social/tags/api360" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#api360</a> <a href="https://mastodon.social/tags/apiDocumentation" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#apiDocumentation</a>

IT NewsAPI Design Patterns: Best Practices for Building Resilient APIs - Introduction API design patterns are essential for creating reliable, scalable, an... - <a href="https://readwrite.com/api-design-patterns-best-practices-for-building-resilient-apis/" rel="nofollow noopener noreferrer" target="_blank">https://readwrite.com/api-design-patterns-best-practices-for-building-resilient-apis/</a> <a href="https://schleuss.online/tags/apidesignpatterns" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#apidesignpatterns</a> <a href="https://schleuss.online/tags/apidocumentation" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#apidocumentation</a> <a href="https://schleuss.online/tags/developerportal" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#developerportal</a> <a href="https://schleuss.online/tags/apimarketplace" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#apimarketplace</a> <a href="https://schleuss.online/tags/apigateways" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#apigateways</a> <a href="https://schleuss.online/tags/restfulapis" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#restfulapis</a> <a href="https://schleuss.online/tags/apigateway" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#apigateway</a> <a href="https://schleuss.online/tags/developer" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#developer</a> <a href="https://schleuss.online/tags/apidesign" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#apidesign</a> <a href="https://schleuss.online/tags/digital" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#digital</a> <a href="https://schleuss.online/tags/tech" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#tech</a> <a href="https://schleuss.online/tags/rest" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#rest</a> <a href="https://schleuss.online/tags/api" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#api</a>

Miguel Afonso Caetano<a href="https://tldr.nettime.org/tags/TechnicalWriting" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#TechnicalWriting</a> <a href="https://tldr.nettime.org/tags/API" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#API</a> <a href="https://tldr.nettime.org/tags/APIDocumentation" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#APIDocumentation</a> <a href="https://tldr.nettime.org/tags/SoftwareDocumentation" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#SoftwareDocumentation</a> <a href="https://tldr.nettime.org/tags/TechnicalWriter" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#TechnicalWriter</a>: "As you know from our other videos on technical documentation, writing docs is an extremely important part of creating software that users will love. But what if developers are the users? Let’s talk about API documentation and why it matters" <a href="https://www.youtube.com/watch?v=39Tt1IkLiQQ&t=223s" rel="nofollow noopener noreferrer" target="_blank">https://www.youtube.com/watch?v=39Tt1IkLiQQ&t=223s</a>

Recherches récentes

Options de recherche

Administré par :

Statistiques du serveur :

#apidocumentation