API Improvement Proposals
Welcome AIPs are design documents that summarize Google's API design decisions. They also provide a framework and system for others to document their own API design rules and practices. AIPs are a combination of design guidance and a system we use to manage and track that guidance. Learn more about how the AIP program works in the first AIP!
Node.js API Table
Static method: Buffer.copyBytesFrom(view[, offset[, length]])
ドキュメントエンジニアリングとAPIドキュメンテーション
LINE株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。 LINEヤフー Tech Blog はじめにテクニカルライター（technical writer）という言葉を聞くと、ほとんど「ライター」という単語だけ見て「文章を書く人」と思いがちです。もちろん間違いではありません。しかし、実際にキーボードを叩いて文章を書く仕事は、テクニカルライター業務のほんの一部です。1日にどれくらい文章を書くか測定したことはないですが、テクニカルライターのトム・ジョンソン（Tom Johnson）によると、仕事をする時間の約10%が文章を書く時間だそうです。 では、その他の時間には何をしているのでしょうか。これもトム・ジョンソンによると、開発者のインタビュー、ほかの人が書いたドキュメントのレビュー、アプリの動作を録画するためにiPhone
Zalando RESTful API と イベントスキーマのガイドライン
License: CC-BY-SA 3.0 © Zalando SE 2020 & CC-BY-SA 3.0 © kawasima 2020 Zalandoのソフトウェアアーキテクチャは、疎結合なマイクロサービスを中心としており、 それらはJSONペイロードをもつRESTful API群によって、機能が提供されています。 小さなエンジニアのチームは、自分たちでAWSアカウントにこれらのマイクロサービスを デプロイしたり運用したりしています。 私たちのAPIは、その多くが私たちのシステムが何をするのかを完全に表現しており、 それゆえに貴重なビジネス資産となっています。 Zalandoがとあるオンラインショップから価値あるファッションプラットフォームへと変貌を とげるために、私たちは新しいオープンプラットフォーム戦略の展開をはじめました。 なので、高品質で長持ちするAPIの設計は、私たちにとっ
API 設計ガイド | Cloud APIs | Google Cloud
フィードバックを送信 API 設計ガイド コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。 変更履歴 はじめに これは、ネットワーク API の一般的な設計ガイドです。2014 年以来 Google 内部で使用され、Cloud API やその他の Google API を設計するときに Google が従うガイドです。この設計ガイドは、外部のデベロッパーへの情報提供と、互いの連携作業の効率化のためにここで共有されています。 Cloud Endpoints のデベロッパーには、このガイドは、gRPC API を設計するときに特に役立つことがあり、そのような場合にはこれらの設計原則を使用することを強くおすすめします。ただし、このガイドの使用は必須ではありません。Cloud Endpoints と gRPC はガイドに従わなくても使用できます。 このガイドは、gR
Build optimized websites quickly, focus on your content | Docusaurus
Build optimized websites quickly, focus on your content Powered by MDXSave time and focus on text documents. Simply write docs and blog posts with MDX, and Docusaurus builds them into static HTML files ready to be served. You can even embed React components in your Markdown thanks to MDX. Built Using ReactExtend and customize your project's layout by writing React components. Leverage the pluggabl
Documentation Driven Contractsについて調べてみた - mookjp.io
Documentation Driven Contractsについて調べてみた May 15, 2017 ( May 15, 2017 更新 ) モチベーション 最近業務で、社内の他のチームに提供するAPIを開発している。 関わっている人が少なければ、みんなで近くに座って都度仕様について相談していけばいい。（感覚的には〜7人くらい？） しかし、会社全体の人数が多く、関わるチームも複数いるため（サービスのモバイルアプリ担当、Webフロント担当、バックエンド担当…など）包括的で都度更新されるドキュメントがないと開発効率が悪い。 とはいえ、API提供チームとしては、実装になるべく多くの時間を使いたい。具体的には以下の条件を満たす手法があればよい: ドキュメント作成にかける時間を短くできる 作成したドキュメントの内容が正確（最新であることが必須） 一番原始的な手法として、ドキュメントをちまちま人手
こんなに使える！今どきのAPIドキュメンテーションツール
This document summarizes a microservices meetup hosted by @mosa_siru. Key points include: 1. @mosa_siru is an engineer at DeNA and CTO of Gunosy. 2. The meetup covered Gunosy's architecture with over 45 GitHub repositories, 30 stacks, 10 Go APIs, and 10 Python batch processes using AWS services like Kinesis, Lambda, SQS and API Gateway. 3. Challenges discussed were managing 30 microservices, ensur
翻訳: WebAPI 設計のベストプラクティス - Qiita
これは Enchant の開発者である Vinay Sahni さんが書いた記事「Best Practices for Designing a Pragmatic RESTful API」1を、ご本人の許可を得て翻訳したものです。 RESTful な WebAPI を設計しようとすると、細かなところで長考したり議論したりすると思います。また、他の API に倣ってやってはみたものの、本当にそれでいいのか、どうしてそうしているのか分からない、何てことも少なくはないと思います。 この記事では、そのようなハマリどころについて Vinay さんなりの答えを提示し、簡潔かつ明快に解説してくれています。 今後 WebAPI を設計される方は、是非参考にしてみてください。 なお、誤訳がありましたら編集リクエストを頂けると幸いです。 まえがき アプリケーションの開発が進むにつれて、その WebAPI を公
Design Driven API Development
This document discusses design-driven API development using API description languages like Swagger and RAML. It recommends generating documentation and code from a single API schema to avoid inconsistencies. This approach allows server code and related resources like SDKs and tests to be generated from the schema rather than developed separately. The document provides an example using Swagger-Node
Ramda Documentation
A special placeholder value used to specify "gaps" within curried functions, allowing partial application of any combination of arguments, regardless of their positions. If g is a curried ternary function and _ is R.__, the following are equivalent: g(1, 2, 3) g(_, 2, 3)(1) g(_, _, 3)(1)(2) g(_, _, 3)(1, 2) g(_, 2, _)(1, 3) g(_, 2)(1)(3) g(_, 2)(1, 3) g(_, 2)(_, 3)(1)
REST APIドキュメント生成パターン - ✘╹◡╹✘
REST API用のドキュメントを生成するときにどうやってるかについて雑記を残しとく。 概要 実装とドキュメントの乖離を避けるためには、同じ意味情報を二箇所以上に定義することを避ける必要がある。そのための方法として、実装それ自身か、もしくは実装が参照している何らかのメタデータを元にしてドキュメントを生成したり、テストの実行結果からドキュメントを生成するというパターンがある。 テストから Cookpadでは、autodocというライブラリを利用して、RSpecでテストを実行している途中で得られたメタデータからドキュメントを生成している。これはテストの実行結果からドキュメントを生成するパターン。 これは実現方法としてはかなり特殊な部類。このパターンが最も効果的に働くのは、ドキュメント生成のために余分な開発コストはあまり掛けたくないが、テストは真面目に書いている OR 真面目に書いてほしい、とい
HerokuのAPIデザイン
Herokuが自ら実践しているAPIデザインガイドをGithubに公開した． “HTTP API Design Guide” このガイドは些細なデザイン上の議論を避けて，ビジネスロジックに集中すること目的としている．Heroku特有なものではなく，一般にも十分適用できる知見となっている． 最近は，モバイル向けにAPIをつくることも多いため，勉強もかねて抄訳した．なお内容は，HTTP+JSONのAPIについて基本的な知識があることが前提となっている． 適切なステータスコードを返す それぞれのレスポンスは適切なHTTPステータスコード返すこと．例えば，“成功"を示すステータスコードは以下に従う． 200: GETやDELETE，PATCHリクエストが成功し，同時に処理が完了した場合 201: POSTリクエストが成功し，同時に処理が完了した場合 202: POSTやDELETE，PATCHリク
GitHub - slatedocs/slate: Beautiful static documentation for your API
Clean, intuitive design — With Slate, the description of your API is on the left side of your documentation, and all the code examples are on the right side. Inspired by Stripe's and PayPal's API docs. Slate is responsive, so it looks great on tablets, phones, and even in print. Everything on a single page — Gone are the days when your users had to search through a million pages to find what they
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Provable APIs | Q.E.D. Code
api-guidelines/Guidelines.md at master · microsoft/api-guidelines
GitHub - TypeStrong/typedoc: Documentation generator for TypeScript projects.
ReadMe
GitHub - interagent/http-api-design: HTTP API design guide extracted from work on the Heroku Platform API
What is | HelloReverb.com