外部パートナーとのAPI連携時に気をつけるポイント - 10X Product Blog
はじめに こんにちは！yamakazu (@yamarkz) です。 近所の行きつけスーパーがサミットストアになったのですが、品揃えがとても良く、お店の雰囲気も明るくて、仕事終わりの買い物が最近の楽しみになってます 🥳 🛒🥗 さて今回は、開発方面のナレッジとして外部API連携の話を紹介します。非常にニッチな領域の話題ですが、わかる人にはわかるような内容です。 興味のある方はぜひ最後まで読んでみてください。 動機 新しく外部API連携の開発に着手するメンバーの助けになりたい、より良い外部API連携を実現したいという思いから、これまで開発を経験してきた中で理解した勘所を紹介します。 元々は社内向けに書き溜めておいたナレッジメモの内容ですが、特別社内に留めておく必要性もないので、せっかくならブログにしてしまおうと思い、ここで筆を取りました。 これは社内の同僚に向けた内容でありながら、似た境
ProtobufでREST APIを快適に開発する方法のご紹介 - TIER IV Tech Blog
こんにちは、ティアフォーで認証認可基盤を開発している澤田です。 最近取り入れたProtobufで、素晴らしいREST APIの開発体験をしたのでご紹介します。 なお、ティアフォーではマイクロサービスを支える認証認可基盤を一緒に開発いただけるメンバーを募集しています。ご興味のある方は下記ページからご応募ください。 herp.careers 実現したかったこと マイクロサービス間連携のAPI開発において、以下の条件を満たすやり方を探していました。 スキーマを最初に定義してリクエストとレスポンスの型が自動で生成される ドキュメント（openapi.yaml）が生成される バリデーションが定義できて、その実装が自動で生成される 実現方法 Go言語で開発する場合はgo-swaggerでも実現できますが、本記事では、Protobufで実現できるgRPC Gatewayとprotoc-gen-valid
API設計スキルを次のレベルに引き上げるベストプラクティス22選 - Qiita
本記事は、Mohammad Faisal氏による「22 Best Practices to Take Your API Design Skills to the Next Level」（2021年4月15日公開）の和訳を、著者の許可を得て掲載しているものです。 REST API設計のための実践的アドバイス Photo by Andrea Piacquadio from Pexels はじめに すべてが分かりにくく、ひどいAPIに不満を感じたことはありませんか？私はそうです。 マイクロサービスの世界では、バックエンドAPIの一貫した設計が不可欠です。 今日は、知っておくべきベストプラクティスについて、簡潔に説明します。さあ始めましょう！ 用語 API設計は、リソース指向設計というものに従います。3つの重要な概念で構成されています。 リソース：データの一部（例：ユーザー） コレクション：リソー
Botが雑談に応えられるようにするWEB APIを公開してみた話【個人開発】 - Qiita
追記 本記事で紹介する「Chaplus雑談対話API」の後継となるAPIを公開しました。下記の記事で紹介をしているので、合わせてこちらもご覧ください。 https://qiita.com/maKunugi/items/14f1b82a2c0b6fa5c202 本記事で紹介するAPIよりも精度が向上している他、文脈を考慮した会話ができるようになっています。 対象読者 チャットボット等を初めとする「対話型」のサービスに興味がある方 チャットボット等の開発に興味がある方 チャットボットに雑談を話させたい方 対話システムと人間の対話に興味がある方 チャットボットに必要な「雑談力」 こんにちは、maKunugiです。 チャットボットを初めとする「対話型」のサービスが様々な場面で活用されている昨今ですが、対話型サービスの開発で非常に厄介なのが、「ユーザからの問いかけに応答するためのセリフを用意しきれな
雑談AIかたらい
(注1)かたらいベーシックプラン 月1~20.000コールまで80,000円(税抜き) 以降、2万コール毎80,000円 (注2) かたらいエンタープライズプラン 月1-50.000コールまで200,000円(税抜き) 以降、5万コール毎200,000円
A3RT
DETAIL [Small Talk API] 完全自動の日常会話を可能にするAPIです。 例えばあなたの運用しているWebサイトでAPIを呼び出しサイト上でユーザとの会話を可能にします。 さらにユーザとの会話を学習していくことでより賢く・より自然な会話を実現します。 NOTES 個人情報について： 他人の名称・メールアドレス・住所・電話番号など個人を特定しうる情報はアップロードしないでください。 推奨ブラウザについて： 本ページはGoogle Chromeを推奨しています。 Google Chrome以外のブラウザでは正しく作動しないケースがあります。 DEMO DEMOの使用には、API KEYが必要になります。
HTTP検索条件、GETにするか？POSTにするか？ | フューチャー技術ブログ
はじめにTIG DXユニット 1真野です。 RESTfullとかRESTishな方針でWebA PIの横断検索を設計する際にチーム内で方針について議論したやり取りの備忘記事です。 注意としてB2C向けなWeb APIを提供するというよりは、主に企業間または企業内部で使われるようなAPIの設計のバイアスがあります。LSUDs（Large Set of Unknown Developers）かSSKDs（Small Set of Known Developers）で言えば、確実にSSKDs脳で記事が書かれています。 REST API広く使われているため日本語記事も多数です。実践RESTful HTTP - InfoQ や、0からREST APIについて調べてみた など良さそうな記事が沢山でてくるの読むと良いでしょう。一般的な設計方法はやや古いですがWeb API: The Good Parts
Web APIのトランザクション - kawasima
更新APIの難しさ ネットワークの向こう側にあるリソースを更新するのは、単純なTCP/IPの仕組みでは難しい。その上に構成されたシンプルなプロトコルである単純なHTTPで実現しようとすると、以下に示すような箇所でエラーの発生可能性があり、双方で等しく検知することができないケースが存在し、同期的なリカバリが困難である。 エラーの発生箇所 1. クライアント→サーバの接続エラー 2. クライアントからリクエスト送信したがサーバに届かない。 3. サーバが不完全なメッセージを受信した。 4. メッセージがサーバの処理キューに入らない。 5. サーバで処理が正常に完了しない。 6. サーバからレスポンスを返そうとしたが接続が切れている。 7. サーバからレスポンスを返したが、クライアントに届かない table:エラー検知 クライアント サーバ ① コネクションタイムアウト,... 検知不能 ② ソ
HTTP APIの詳細なエラー情報をレスポンスに持たせるための仕様
今日では HTTP(s) で API が公開されることは当たり前の時代ですが、エラーをアプリケーションにどう伝えるかは、個々の API の設計に依存していました。特に、HTTP ステータスコードは有限であり、元々持っている意味があるので、自由に使うことはできません。API はそのドメインごとにもっと複雑で細かなエラー情報があるはずで、それらはレスポンスボディに載せてアプリケーションに伝えることになりますが、その書式に規定は今までありませんでした。 HTTP API にて、アプリケーションにエラー情報を伝達するための（レスポンスボディに載せられる）標準的な形式が、RFC7807 Problem Details for HTTP APIs で定められています。適用例としては、以下のようになります。 HTTP/1.1 403 Forbidden Content-Type: application
OpenAPI関連のサイト・ツールまとめ | GiFT（ギフト）株式会社
OpenAPI関連のサイト・ツールまとめ2020.10.29 OpenAPI関連のサイトやツールなどの情報が種々雑多にあるので、自分の中での整理と忘備録として残すためにまとめました。（2020年10月時点） 概要OpenAPIとはOpenAPIという表現が使われた場合、恐らくそれらの多くはOpenAPI Specification（以下OAS）に基づいてJSONやYAMLで記述されたREST APIの仕様書（スキーマ）を指しているように思います。 OASはREST APIの仕様を記述するための規格であり、それ自体がなにかのツールやサービスを提供するものではありません。 とはいえ関連するツールやサービスも普及してきているので、あまり言葉の意味を気にしすぎる必要もないかもしれませんが。 OpenAPI Specification (v3.0.3)Implementer’s Draft (OAS
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を設計してみるとどんなインターフェイスがいいのか、どんな形式がいいのかといった疑問が次々と出てきます。
APIドキュメントを支える技術 - Qiita
最近のウェブ開発では各機能ごとをAPIでつなぎ込む時代になっています。 そのため、各チームが開発をしていく上で、 他のチームにAPIの仕様を伝える方法をきちんとまとめておく必要が出てきています。 そんな中でAPIドキュメントにどのような役割が求められていて どのような選択肢があるか、一旦自分の把握している知識をまとめています。 (ここで書いているAPIは、httpでアクセスしたら、JSON形式でレスポンスを返すウェブサービスのAPIを指しています) APIドキュメントを用意する上で、すぐにぶつかる壁 APIドキュメントを用意する場合に、何も考えずにExcelやwikiにまとめると、早い段階で メンテナンスのコスト の問題にぶつかります。 『APIドキュメントを書く時間がない』 『本当にドキュメント通りの結果が返ってくるか、試してみないとわからない』 『実際に返ってくるAPIとレスポンスが違
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
OpenAPI (Swagger) 超入門 - Qiita
Swaggerについて | chobilog