OpenAPI? What Is That? Is That Tasty?ReactJS: Keep Simple. Everything can be a component!
POSTリクエストを冪等処理可能にするIdempotency-Keyヘッダの提案仕様 - ASnoKaze blog
はじめに HTTPリクエストには冪等なものと非冪等なものがあります。 仕様上、GETやOPTIONSは冪等であり、同じリクエストであれば何度行っても問題ありません。そのため通信上エラーが起こっても自動的にリトライすることが出来ます。 一方で、POSTリクエストは冪等ではありません。同じリクエストでも複数回行うと、結果が変わってしまいます。投稿や課金APIであれば2重に処理されてしまいます。 POSTリクエスト中にタイムアウトが発生した時に、サーバに処理される前にタイムアウトしたのか、サーバが処理したあとにレスポンスを返そうとしたところでタイムアウトしたのかクライアントは区別できません。そのため、POSTリクエストを一概にリトライすることは出来ません。 そこで、リトライにより複数回同じPOSTリクエストを受け取っても、同じものと識別できるように識別子をHTTPリクエストに付加できるようにする
REST vs. GraphQL: A Critical Review – Good API
Are you building an API? Here is the idea: If you have never heard about the REST architectural style constraints and their implication on the properties of the resulting distributed system and you do not want to (or can’t) educate yourself, use GraphQL. UPDATEI had a keynote on this topic at Nordic APIs Platform Summit 2018. In this talk, I introduce the Framework for evaluation API Paradigms b
REST API フレームワーク Connexion のススメとその作例 - (ひ)メモ
Python の Connexion というフレームワークとそのサンプルアプリケーションを書いたのでその紹介です。 https://github.com/zalando/connexion https://github.com/hirose31/connexion-tiny-petstore Connexion は「API (spec) First」を謳うフレームワークです。 「API First」とは、 ご存じ The Twelve-Factor App の追補として 2016 年に Pivotal 社が提唱したガイドライン Beyond the Twelve-Factor App の中のひとつです。 簡単にいうと、コードを書き始める前にまずAPIの仕様を定める。たとえば昨今のマルチデバイス対応のような複数チームで開発を進めるような現場で、お互いこのAPI仕様を拠り所とすることで、他方の
RESTful API Design. Best Practices in a Nutshell.
Philipp Hauer's Blog Engineering Management, Java Ecosystem, Kotlin, Sociology of Software Development Posted on Mar 4, 2015. Updated on Jun 12, 2022 Designing HTTP and RESTful APIs can be tricky as there is no official and enforced standard. Basically, there are many ways of implementing an API but some of them have proven in practice and are widley adopted. This post covers best practices for bu
Dockerを使ってSwaggerの環境を整えてAPI Gatewayにインポートする | DevelopersIO
API Gatewayを使いこなしたい そろそろAPI Gateway使いこなしたい今日このごろですが、API Gatewayには、Swaggerの定義ファイルをインポートというボタンがあって、こっちを先にやってみようと思いました。環境周りの整備には以前学んだDockerを使えそうですので、試してみたいと思います。 Swagger Editorで編集する エディタの環境を整えます。 docker pull swaggerapi/swagger-editor docker run -d -p 8001:8080 swaggerapi/swagger-editor ここで作成したJSONとかYAML形式のファイルをエクスポートして保存しておきます。 Swagger UIのインストール Swagger UIは、Swaggerの定義ファイルからキレイな公開用のAPI確認サイトを作ってくれます。 $
Python REST APIs With Flask, Connexion, and SQLAlchemy – Part 1 – Real Python
Most modern web applications are powered by a REST API under the hood. That way, developers can separate the front-end code from the back-end logic, and users can interact with the interface dynamically. In this three-part tutorial series, you’ll build a REST API with the Flask web framework. You’ll create a foundation with a basic Flask project then add endpoints and connect them to a SQLite data
Developers.IO 2018 で「API 設計」の話をしてきた #cmdevio2018 | DevelopersIO
緊張すると声がアムロ・レイになる都元です。 ここからしばらく、キャッチコピーの迷走期が始まりますのでよろしくお付き合いください。 さて、去る 10/5 (金) 秋葉原 UDX にて開催された Developers.IO 2018、その中で 「クラスメソッドにおける Web API エンジニアリリングの基本的な考え方と標準定義」 という仰々しいタイトルで1講座持たせていただきました。 スライド 話したかったことと、話したこと 本セッションで話したかったことはだいぶ多岐にわたり、当然 40 分では話しきれないので、当初は次の 2 テーマに絞ってお話しようと考えてスライドを作っていました。 アプリケーション動作ログガイドライン RESTful / リソース指向 API 設計 しかし実際にスライドを作ってみると、それぞれで 40 分の規模となってしまい…。 ログの話は断腸の思いで見送りとさせていた
GraphQLとRESTfulについて今日考えてたこと Backend for Usecase/Resourceについて - 余白
DISCLAIMER: これは本当にただのメモ書きで、これがベストプラクティスだとかいう話ではないので、同じようなことを考えてる人いたら今度議論しましょうよ、って程度の話の種。 GraphQLを使うべきスポット、RESTfulが好ましいスポットについて今日ぼんやり考えていて、なんとなく言語化ができる気がするので文字起こししてみる。 Backend for UsecaseとBackend for Resource バックエンドのAPIには2種類あって、 「データ」を構成する「リソース」を提供するもの アプリケーションの「ユースケース」がもつシナリオのなかで登場する「データ」部分を埋めるためのもの を区別することが必要そう、と思っている。 まず前者を Backend for Resource (BFR)と呼ぶことにする。これはわかりやすくて、これはまさしくRESTfulそのもの。 RDBやそう
Cat as a service (CATAAS)
Is a REST API to spread peace and love (or not) thanks to cats. Have 0 cats for now Give me a cat
綺麗な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 を公
RESTのベストプラクティス | POSTD
現在ではREST APIはとても一般的な話題です。ほとんどすべてのWebアプリケーションの一部分となっています。シンプルで一貫性があり実際的なインターフェースは必須です。これは皆さんのAPIを他の人が使うことをとても容易にします。皆さんにとってはRESTの実践が日常的に感じられるかもしれませんが、RESTをあまり尊重しない人々もよく見かけます。これがRESTについて投稿するきっかけでした。 この記事にはRESTfulなAPIを設計する時に考慮すべきベストプラクティスがあります。 注意 : ここでのベストプラクティスは、私が過去の経験に基づいて良いと考える事例です。もし違う考えをお持ちであれば、お気軽にメールをくだされば意見交換できると思います。 APIのバージョンを示す APIのバージョンは必須であるべきです。これがあると時間が経ってAPIが変わっても影響を受けません。その方法の1つはUR
RESTとJSON、スキーマ定義について思うところ
mozaic.fm #7 RESTや#mozaicfm REST を聴いての感想、それから「Web+DB vol82のWebAPIデザインの鉄則」に触発されたので書こうと思う。 REST設計について WebAPIを設計するうえでRESTが重要であることは周知のとおりである。 “Constraints are liberating”「制約は自由をもたらす」 @t_wadaさんがおっしゃっているように、RESTを前提にすれば、「アーキテクチャとしてもそうだし、アプリケーションフレームワークも「適切な制約」を設けることで設計のコストが下がる」という大きなメリットが生まれる。 しかし、相変わらずリソース設計やらインターフェース設計やらで悩んでおられる方も多いと聞く。 その一方で個人的には適切なフレームワークを使えばREST設計で悩まなくてもよいはず(※3)という思いもある。 インターフェース設計な
拡張可能なWeb APIの設計原則と、バージョン番号を使う理由について
APIのバージョニングは限局分岐でやるのが良い - Hidden in Plain Sightにはブコメしたのですが、Rebuild: 35: You Don't Need API Version 2 (Kenn Ejima)でも本件に言及があったようなので、少し一般論を書いておきたいと思います。 ■Web APIの設計原則について そもそも、良いAPIとはどのような特性をもつものでしょうか？ 一般的に、以下の２点が挙げられると思います。 拡張が容易である 拡張時に後方互換性を破壊しない ウェブの場合は、これに加え、 スケーラブルである HTTPに起因する問題に上手に対処できる ことが求められます。 前２者はウェブに限らない要件です。これを満たす設計手法としては、 リクエストおよびレスポンスのパラメータを拡張可能に 互換性を壊す拡張が必要な場合は、関数名を変える 古い関数は従来と同じ機能を
次世代Webアーキテクチャーの話 (CROSS2014を聞いて)
CROSS2014の次世代Webセッションを見て来た。 セッションの前半で議論されていたプロトコル編はしっかりとした方向性が示されていたが、後半のアーキテクチャー編は現状の混沌とした話が多くて、方向性というか新しいビジョンを示すまではいけなかった印象だった。 それは、サーバのアーキテクチャーが成熟していることも理由の一つなのかもしれない。 しかし、アーキテクチャーこそ方向性を示すのが重要だろうと思うので、個人的に考えていることをまとめることにした。 Webスケールを実現する技術とリアルタイムWebの方向性 リアルタイムWebというわけではないが、密結合なプロトコルはことごとくインターネットで玉砕されてきた歴史がある。 古くはCORBA IIOP、DCOMの失敗。それからSOAPの失敗。 （ちなみに、IIOPのIはInternetで、当初は大規模なインターネットスケールで分散させようとしたこ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Google Cloud 公式ブログ
kong でアクセス制御 - momota.txt
API アグリゲーション: Kong - momota.txt
HTTP API の設計方向