すぐに役に立つものはすぐに陳腐化してしまうから方法ではなく設計の本を読む - API Design Patterns の読書感想文 - じゃあ、おうちで学べる
あなたがさっきまで読んでいた技術的に役立つ記事は、10年後も使えるでしょうか？ほとんどの場合でいいえ はじめに 短期的に効果的な手法や知識は、ソフトウェア開発の分野において、急速に価値を失う傾向があります。この現象は、私たちが何を重点的に学ぶべきかを示唆しています。最も重要なのは、第一に基本的な原理・原則、そして第二に方法論です。特定の状況にのみ適用可能な知識や即座に結果を出すテクニックは、長期的には有用性を失う可能性が高いです。これは、技術や手法が時間とともに進化し、変化していくためです。 learning.oreilly.com 「API Design Patterns」は、このような考え方を体現した書籍です。しかも480 ページもあります。本書は単なる手法の列挙ではなく、Web APIデザインの根幹をなす原則と哲学を探求しています。著者のJJ Geewax氏は、APIを「コンピュータ
ヨドバシの中の人が語る、開発中のヨドバシAPIが目指す機能、仕組み、そしてセキュリティ（前編）
ヨドバシカメラは現在、お客様との接点をドメインとして設計する新たなAPIを開発中であることを、クリエーションラインが主催し10月27日に開催されたイベント「Actionable Insights Day 2023」で明らかにしました。 REST APIとして実装される予定のこのAPIについて同社は「ヨドバシスタッフの魂を注入する」としており、厳重なセキュリティやユーザーフレンドリーで高い利便性などが追求されています。 ヨドバシAPIがどのように設計され、開発、実装されていくのか。その中味が紹介されたセッションの内容を見ていきましょう。 本記事は前編と後編の2本の記事で構成されています。いまお読みの記事は前編です。 疎結合なのに一体感、ヨドバシAPIがつなぐ社会 株式会社ヨドバシカメラ 代表取締役社長 藤沢和則氏。 ヨドバシカメラの藤沢と申します。本日はまずこの貴重な機会をいただきありがとう
REST API設計者のための有名APIのURL例
元々Qiitaに投稿していたものをZennに移行しました。 最初の公開日は2016-01-03のため古い内容を含みます。 ご了承の上ご利用ください。 概要 初心者ながらもAPIを設計する機会があり、 有名どころをパクれば参考にすればいい設計になりそうな気がするので、 まとめておきます 今回の話の範囲 REST 今回はこちらを読んでREST APIを設計することにしたので、 RESTのみ扱います 詳細説明について 各APIの詳細な説明は今回の趣旨に反するので省きます API設計のポイントはこちらの記事がわかりやすいと感じたので、 参考にします エラーについて エラーの比較を行っている記事もあり、 すごく参考になっているのでリンクしておきます 「WebAPIでエラーをどう表現すべき？15のサービスを調査してみた」 実際のAPI例 間違っていたり、更新されたり、足りなかったりした場合はお知らせ下
Netflixにおける実用的なAPI設計: gRPCとFieldMask | pyspa
Netflix Tech BlogのgRPC APIに関する以下の２つの記事に感銘を受けたので、ここにその概要を日本語で記します。 (めんどくさかったので)翻訳の許可は取ってませんが、再構成してますし元のJavaではなくPythonで書き直していますので、容赦して下さい… Practical API Design at Netflix, Part 1: Using Protobuf FieldMaskPractical API Design at Netflix, Part 2: Protobuf FieldMask for Mutation OperationsまとめgRPCでは、FieldMaskをうまく使うことで、必要な情報だけ取得したりあるいは与えたりしたりできまっせ第一部まずField Maskをどのように使うかを述べています。 背景Remote Callというものは、そもそもコ
RESTのベストプラクティス | POSTD
現在ではREST APIはとても一般的な話題です。ほとんどすべてのWebアプリケーションの一部分となっています。シンプルで一貫性があり実際的なインターフェースは必須です。これは皆さんのAPIを他の人が使うことをとても容易にします。皆さんにとってはRESTの実践が日常的に感じられるかもしれませんが、RESTをあまり尊重しない人々もよく見かけます。これがRESTについて投稿するきっかけでした。 この記事にはRESTfulなAPIを設計する時に考慮すべきベストプラクティスがあります。 注意 : ここでのベストプラクティスは、私が過去の経験に基づいて良いと考える事例です。もし違う考えをお持ちであれば、お気軽にメールをくだされば意見交換できると思います。 APIのバージョンを示す APIのバージョンは必須であるべきです。これがあると時間が経ってAPIが変わっても影響を受けません。その方法の1つはUR
API 設計: gRPC、OpenAPI、REST の概要と、それらを使用するタイミングを理解する | Google Cloud 公式ブログ
※この投稿は米国時間 2020 年 4 月 11 日に、Google Cloud blog に投稿されたものの抄訳です。 ほとんどのソフトウェア デベロッパーがご存じだと思いますが、API 設計には RPC と REST の 2 つの主要なモデルがあります。モデルに関係なく、ほとんどのモダン API は、なんらかの方法で同じ HTTP プロトコルにマッピングすることによって実装されます。また、RPC API 設計では、RPC モデルの範囲から外れずに HTTP から 1 つまたは 2 つのアイデアを採用することが一般的になっています。これにより、API 設計者に提示されるオプションの範囲が広がりました。この投稿ではこれらのオプションについて説明し、どれを選ぶか決める際に役立つガイダンスを提供します。 gRPC は RPC API を実装するためのテクノロジーで、HTTP 2.0 をその基盤
Developers.IO 2018 で「API 設計」の話をしてきた #cmdevio2018 | DevelopersIO
緊張すると声がアムロ・レイになる都元です。 ここからしばらく、キャッチコピーの迷走期が始まりますのでよろしくお付き合いください。 さて、去る 10/5 (金) 秋葉原 UDX にて開催された Developers.IO 2018、その中で 「クラスメソッドにおける Web API エンジニアリリングの基本的な考え方と標準定義」 という仰々しいタイトルで1講座持たせていただきました。 スライド 話したかったことと、話したこと 本セッションで話したかったことはだいぶ多岐にわたり、当然 40 分では話しきれないので、当初は次の 2 テーマに絞ってお話しようと考えてスライドを作っていました。 アプリケーション動作ログガイドライン RESTful / リソース指向 API 設計 しかし実際にスライドを作ってみると、それぞれで 40 分の規模となってしまい…。 ログの話は断腸の思いで見送りとさせていた
API 設計ガイド | Cloud API Design Guide | Google Cloud
フィードバックを送信 API 設計ガイド コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。 変更履歴 はじめに これは、ネットワーク API の一般的な設計ガイドです。2014 年以来 Google 内部で使用され、Cloud API やその他の Google API を設計するときに Google が従うガイドです。この設計ガイドは、外部のデベロッパーへの情報提供と、互いの連携作業の効率化のためにここで共有されています。 Cloud Endpoints のデベロッパーには、このガイドは、gRPC API を設計するときに特に役立つことがあり、そのような場合にはこれらの設計原則を使用することを強くおすすめします。ただし、このガイドの使用は必須ではありません。Cloud Endpoints と gRPC はガイドに従わなくても使用できます。 このガイドは、gR
同僚のコードレビューでこんなにクラスの設計が良くなったという話 - Qiita
弊社では、案件とは関係のないプロジェクトでも業務時間中にみんなにコードレビューを依頼できる時間が確保されています(参加は任意)。案件のコードレビューを依頼したり、ちょっとした個人の制作物を見てらったりと使い方は色々です。 先日、TypeScriptの練習にQiitaのAPIを叩いていて記事を表示するブログウィジェットを作成しました。このウィジェットのレビューを依頼したところ、クラスの設計について具体的な指摘と、それに対する改善を経験できたのでこの記事に記載します。 今回作ったQiitaWidgetの要件 Qiitaの公式APIV2から記事とユーザー情報を取得し、HTMLテンプレートに表示する 投稿の合計いいね数を算出するために、あるユーザーの投稿を全件取得する (このために複数回リクエストの送信とレスポンスデータの結合を行う) パラメータによってユーザー、いいね数によるソート、表示件数、ラ
今さらだけど「Web API: The Good Parts」 を読んだので自分なりにまとめてみる - Qiita
今さらですが、「Web API: The Good Parts」を読みました。 せっかくなので自分なりにまとめてみます。 1. URLについて 短く入力しやすいURL ×：http://sample.com/search-api/service/api/search ○：http://sample.com/api/search 人間が読んで理解できるURL ×：http://sample.com/api/u ○：http://sample.com/api/user 略すのもだめ products -> prod 大文字小文字が混在していないURL ×：http://sample.com/api/getUserInfo ○：http://sample.com/api/user 基本はすべて小文字 改造しやすい（Hackable）なURL ×：http://sample.com/api/ite
セマンティック バージョニング 2.0.0
セマンティック バージョニング 2.0.0 概要 バージョンナンバーは、メジャー.マイナー.パッチ とし、バージョンを上げるには、 APIの変更に互換性のない場合はメジャーバージョンを、 後方互換性があり機能性を追加した場合はマイナーバージョンを、 後方互換性を伴うバグ修正をした場合はパッチバージョンを上げます。 プレリリースやビルドナンバーなどのラベルに関しては、メジャー.マイナー.パッチ の形式を拡張する形で利用することができます。 導入 ソフトウェア・マネージメントの世界には、「依存性地獄」と呼ばれる恐ろしいものがあります。あなたのシステムが大きく成長すればするほど、さまざまなパッケージを組み込めば組み込むほど、自分が地獄の底にいることにいつか気づくでしょう。 多くの依存性を有しているシステムにとって、新しいバージョンがリリースされることは悪夢でしかありません。厳密に依存関係を指定し
API Blueprint | API Blueprint
API Blueprint. A powerful high-level API description language for web APIs. API Blueprint is simple and accessible to everybody involved in the API lifecycle. Its syntax is concise yet expressive. With API Blueprint you can quickly design and prototype APIs to be created or document and test already deployed mission-critical APIs. Tutorial Tools section Focused on Collaboration API Blueprint is bu
RESTfulなWeb APIを設計するときに考えること - Qiita
ApigeeやHerokuのドキュメントに従うのでもよかったんだけど、読んでいく中でやっぱり考えることは出てきたので、あくまで自分のための指針をまとめてます。 包括的なWeb API作成についての知見 HerokuのAPIデザイン | SOTA interagent/http-api-design · GitHub Web API 設計のベストプラクティス集 "Web API Design - Crafting Interfaces that Developers Love" - フリーフォーム フリークアウト Web API Design | Apigee NetFlixもWeb APIの設計についての知見をよく放出してくれてる印象。 設計の基本 基本は /コレクション/名詞 リソースの関係を表したい時に階層化する members/1234/friends 階層は浅く保つ できるだけ/c
HTTP API の設計方向
見てみると、たしかに Get 系の API だとしても POST を利用しているし、API の URL 設計に get_shared_link_file のようによく言われる REST っぽい設計は使っていなかった。 この方針は同意だ。自分は結構前に REST っぽい API を捨てることにした。だからといって REST API がダメだとかは思っていない。 一般ユーザが使う場合の API は REST API であるほうが慣れ親しんでいる場合が多いからだ。 AWS で利用されている HTTP API 仕様AWS の DynamoDB の Erlang/OTP ドライバーを書いているときに気づいたのだが、AWS の一部のサービスはかなり独特な API の仕様になっている。
綺麗なAPI速習会 - Qiita
Wantedly Engineer blogに本速習会資料を閲覧向けに再編しました！ ぜひご覧いただけると幸いです！ 本記事は、綺麗なAPI速習会@Wantedlyの資料として作成されたものです。 同時にこちらのコードも参照してください。 マイクロサービス 流行りのマイクロサービス、何がいいのか 各々自由な言語やArchitectureでサービスを立てられる 障害の影響が部分的 変化に強い 個別デプロイ etc... マイクロサービス化をすすめるにあたり、やりとりは全てAPIで行う 内部のAPIであっても外部に公開できるようなクオリティのAPIを作成し、それを元にサービスを作っていくことが重要 APIGatewayとBFF API Gateway Pattern 公式サイトより 「見た目はモノリシック、実装はマイクロサービス」 一箇所見に行けば全てのAPIを見つけられる 細かい権限管理も可
翻訳: WebAPI 設計のベストプラクティス - Qiita
これは Enchant の開発者である Vinay Sahni さんが書いた記事「Best Practices for Designing a Pragmatic RESTful API」1を、ご本人の許可を得て翻訳したものです。 RESTful な WebAPI を設計しようとすると、細かなところで長考したり議論したりすると思います。また、他の API に倣ってやってはみたものの、本当にそれでいいのか、どうしてそうしているのか分からない、何てことも少なくはないと思います。 この記事では、そのようなハマリどころについて Vinay さんなりの答えを提示し、簡潔かつ明快に解説してくれています。 今後 WebAPI を設計される方は、是非参考にしてみてください。 なお、誤訳がありましたら編集リクエストを頂けると幸いです。 まえがき アプリケーションの開発が進むにつれて、その WebAPI を公
WebAPIでエラーをどう表現すべき？15のサービスを調査してみた - Qiita
2017-01-05 追記 2016年3月にエラーの標準形式RFC7807「Problem Details for HTTP APIs」が提案され、今日現在proposed standard(標準化への提唱)となっています。こちらも是非ご覧ください。 RFC 7807 - Problem Details for HTTP APIs HTTP APIの詳細なエラー情報をレスポンスに持たせるための仕様 最近はREST APIを提供しているサービスが増えてきていますね！また公開されるAPIだけでなく、Microservicesなアーキテクチャを採用して、バックエンドがWeb APIで通信するケースも増えてきているように思います。 APIを使うときはあまり気にしたこともなかったですが、いざAPIを設計してみるとどんなインターフェイスがいいのか、どんな形式がいいのかといった疑問が次々と出てきます。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
フロントエンドエンジニアも知っておきたいgRPC
質の高いAPIを作るための7つの習慣
Heroku HTTP API Design Guide