タグ

APIに関するshunmatsuのブックマーク (29)

  • Web API 設計のベスト プラクティス - Azure Architecture Center

    ほとんどの最新の Web アプリケーションでは、クライアントがアプリケーションと対話する際に使用できる API を公開しています。 適切に設計された Web API には、次をサポートする目的があります。 プラットフォームの独立。 API の内部的な実装方法に関係なく、すべてのクライアントが API を呼び出すことができる必要があります。 そのためには、標準プロトコルを使用し、クライアントと Web サービスが交換するデータの形式に同意できるメカニズムを備えている必要があります。 サービスの進化。 Web API はクライアント アプリケーションから独立して進化し、機能を追加できる必要があります。 API の進化に伴い、既存のクライアント アプリケーションが変更なしに引き続き機能する必要があります。 クライアント アプリケーションが機能を十分に使用できるように、すべての機能が検出可能である

    Web API 設計のベスト プラクティス - Azure Architecture Center
  • GraphQLを徹底解説する記事

    はじめに 今回の記事では、学習や実務でGraphQLを活用する人を対象に、GraphQLの全体像を把握するためのチュートリアル記事になる。記事の対象読者は以下の通りである。 GraphQLの全体像を把握したい人 公式ドキュメントの理解で苦しんでいる人 GraphQLとは GraphQLはWeb APIを開発するためのクエリ言語である。REST APIの問題を解決するために、Facebook(Meta)によって開発された。Web APIの開発において、REST APIと比較して柔軟かつ効率的なアプローチを提供できる。さらに、GraphQLではクライアントが必要なデータの構造を定義することができ、サーバから定義したものと同じ構造のデータが返される。 詳細は後述するが、GraphQL最大の特徴は必要以上に大きなデータが返されることを防ぐことにある。これによって、GraphQLは必要最低限のリク

    GraphQLを徹底解説する記事
  • OpenAIからChatGPTとWhisperに関するAPIがリリースされたのでドキュメントを読み解いてみた | DevelopersIO

    こんちには。 データアナリティクス事業部 インテグレーション部 機械学習チームの中村です。 先日、OpenAIからChatGPTWhisperに関するAPIがリリースされました。 この記事では発表やAPIドキュメントからポイントとなりそうな部分を抽出して紹介したいと思います。 1次情報は以下を参照ください。 冒頭まとめ 冒頭で気付いたポイントを列挙しておきます。 ChatGPT API 入力としてテキスト(content)以外にroleをmessagesに記述(複数可能) 入力にroleを用いた複数のmessageを与えることで、ある程度内容のコントロールが可能 会話の履歴は自動では参照しないため、サービスとしてのChatGPTと同様の動きをさせるには、過去の会話を入力する必要があると推察 課金は入力出力合計のトークン単位($0.002/1ktoken) トークンは単純な単語単位とは異

    OpenAIからChatGPTとWhisperに関するAPIがリリースされたのでドキュメントを読み解いてみた | DevelopersIO
  • Postmanの使い方。初めてのREST APIテスト | Sqripts

    こんにちは!しのののです! 普段、様々なシステムの総合テストを担当していますが、今回初めてWeb APIのテストを担当しました。 今回のAPIテストでは、「Postman」というツールを利用しました。「Postman」は超有名なツールなので使い方をはじめ既知の情報ばかりかもしれませんが、自身の勉強まとめも兼ねて初めて利用した際に調べたこと、使い方、感じたことを経験談として書き連ねていこうと思います。 なお今回書いた内容は、前提として「Postman」を使用したREST APIのテストを対象としています。 REST APIとは? まずプログラミング経験のある方ならお馴染みかと思いますが、API(Application Programing Interface)というのは、簡単に言えばOSや他アプリケーションが提供する機能に、外部アプリからやり取りする為のインターフェースの事です。 Windo

  • APIデザイン・パターン (Compass Booksシリーズ) - たけぞう瀕死ブログ

    APIデザイン・パターン (Compass Booksシリーズ) 作者:JJ Geewaxマイナビ出版Amazon ManningのAPI Design Patternsの日語翻訳版で、GoogleのソフトウェアエンジニアGCPAPIデザイン等にも従事された方が書かれた書籍とのことです。原著はこちら。 API Design Patterns (English Edition) 作者:Geewax, JJManningAmazon なかなか分量があるのと、誤植と思われる箇所や洋書の翻訳にありがちな日語として意味が取りづらい部分が多く、一通り読むのに結構時間がかかってしまいました。 基的にHTTPベースのJSON APIを想定した内容になっています。さすがにGoogleの方が書かれたというだけあり、通常のユースケースでは思い至らないであろう懸念点なども指摘されており「なるほど」と思

    APIデザイン・パターン (Compass Booksシリーズ) - たけぞう瀕死ブログ
  • Auth0 を使って外部サービスのアクセストークンを払い出す | DevelopersIO

    Auth0 で外部サービスのアクセストークンの払い出しができると便利なので、やり方をまとめました。 Twilio や Algolia のようなサービスは、クライアント側で専用のアクセストークンが必要になるケースがあります: API Keys and Access Tokens | Twilio API keys | Algolia Auth0 で外部サービスのアクセストークンを発行することで、払い出すためだけのバックエンドが不要になります。 やり方 Auth0 Actions を使用して、ユーザーのログイン時に以下のことを行います: 外部サービスのアクセストークンを生成します。 Private Claim (Custom Claim) に生成したトークンを含めて、クライアントに渡します。 Custom Library の作成 Actions → Library に移動します。 Build

    Auth0 を使って外部サービスのアクセストークンを払い出す | DevelopersIO
  • Web API: The Good Partsを読んだまとめ - Qiita

    このドキュメントについて Web API: The Good Partsを読んだ内容を友人とやっている勉強会で発表する際に使う資料としてここにまとめた このについて WebAPIを設計する際のベストプラクティスみたいなのを解説した リソース指向とかを事前に知っておくとすんなり入ってくる内容な気がする そんなに厚いではなくサラッと読めるのでおすすめ エンドポイントとリクエストメソッドの設計 エンドポイントの設計 筆者が重要だと考える下記にそって設計を行うと良い。 短く入力しやすい 人間が読んで理解できる 大文字小文字が混在していない 改造しやすい サーバ側のアーキテクチャが反映されていない ルールが統一されている それぞれについて説明していく 1.短くて入力しやすい 読んで字のごとく、短くて入力しやすいということは、シンプルで覚えやすく理解しやすいから 2.人間が読んで理解できる 当た

    Web API: The Good Partsを読んだまとめ - Qiita
  • API Reference · AWS CDK

    Modules The AWS Construct Library is organized into several modules. They are named like this: aws-xxx: service package for the indicated service. This package will contain constructs to work with the given service. aws-xxx¹: a little superscript 1 indicates that his package only contains CloudFormation Resources (for now). aws-xxx-targets: integration package for the indicated service. This packa

  • APIセキュリティのハードニング

    連載3回目となる今回は、前回紹介したシステムに対する攻撃のタイプを紹介し、APIセキュリティのハードニングに則った対応策による堅牢化の手法を紹介します。

    APIセキュリティのハードニング
  • 綺麗なAPIを設計するには気をつけたい5つのポイント | NTT Communications Developer Portal

    綺麗なAPIとは開発者にとって理解しやすく、使いやすいAPIです。さらに提供側にとってはメンテナンスしやすく、拡張性も担保されたものになります。そうしたAPIを設計するのは容易ではありませんが、幾つかのルールを設けておくことでも十分に綺麗に設計できるようになるでしょう。 1. モデル型かアクション型か URLを設計する際にRESTfulに作るのがデファクトになっていますが、その中でもURLの作り方をモデル(ユーザ、商品など)にするか、アクション型(購入する、出席するなど)にするかで分かれます。どちらを採用するにしても明確な基準が必要です。両方を満遍なく取り入れると、非常に分かりづらいものになります。 一般的には GET /users/1 でユーザデータに対する操作であるといった形にします。つまりモデル型です。 となると POST /purchase で購入するというアクションを定義するより

  • API開発の基本 - 銀行APIの開発事例に学ぶ『使いやすい』のデザインプロセス - エンジニアHub|Webエンジニアのキャリアを考える!

    API開発の基 - 銀行APIの開発事例に学ぶ『使いやすい』のデザインプロセス APIは多くのWebシステムにおいて、欠かすことのできない技術です。APIをどのように設計、デザインすれば、ユーザに利便性を提供できるのかを、GMOあおぞらネット銀行 CTOの矢上聡洋さんが解説します。API設計の基、そして実際の銀行APIの設計から、“使いやすい”を生み出すためのデザインプロセスを学びます。

    API開発の基本 - 銀行APIの開発事例に学ぶ『使いやすい』のデザインプロセス - エンジニアHub|Webエンジニアのキャリアを考える!
  • APIゲートウェイとサービスメッシュの違い | gihyo.jp

    注:この説明の後に、APIゲートウェイを使用するかサービスメッシュを使用するか判断する際にアーキテクトの指針となるチートシートを用意しています。チートシートを先に読みたい方は、「⁠チートシート」セクションに進んでください。 長年にわたり、APIマネジメント(APIM)とAPIゲートウェイは、データセンターの内部と外部の両方で最近のAPIユースケースを実装するために使用されてきた主要テクノロジでした。APIゲートウェイテクノロジは、業界で「フルライフサイクルAPI管理」と呼ばれる、より大きく包括的なユースケースを獲得し、この10年の間に大きく発展しました。このテクノロジは、リクエストのデータプレーンのAPIトラフィックを接続し、安全にして管理するランタイムだけでなく、より広い意味でAPIの作成、テスト、文書化、マネタイズ、モニタリングおよび全体的な公開を可能にする一連の機能であり、最初から最

    APIゲートウェイとサービスメッシュの違い | gihyo.jp
  • Jamstackって何なの?何がいいの? - Qiita

    はじめに Jamstackという言葉をきくようになって久しいですが、最近改めてJamstackを学ぶ機会がありました 以前こんな記事も書きましたがライブラリやサービスを並べただけで何も分かってませんでした ようやくちょっとだけ理解してきたので、Jamstackの特徴やそれを支える仕組みをまとめます とりあえず流行りの構成を試してみただけの昔の自分へ届けてあげたい記事です Jamstackとは https://jamstack.org/ JamstackのJamはJavaScript/APIs/Markupの頭文字です JavaScriptAPIをたたいてMarkupを配信することを意味しています これだけ見るとSPAなど単なるWebアプリのようですね Jamstackの特徴としてパフォーマンスの高さとセキュリティの高さがうたわれています これらをどのようにして実現するのか見ていきます J

    Jamstackって何なの?何がいいの? - Qiita
  • 「GraphQL」徹底入門 ─ RESTとの比較、API・フロント双方の実装から学ぶ|ハイクラス転職・求人情報サイト AMBI(アンビ)

    scalar型を新しく定義するためにはscalarキーワードを使います。例えば、Date型を新しく定義するには次のようにします。 scalar Date スキーマではこれだけですが、実際に使う際はGraphQL処理系に対してさらにシリアライズとデシリアライズを定義することになります。 GraphQL組み込みのscalar型は先にあげたものだけなので、例えばバイナリ、日付と時刻、HTML/XML、BigIntなどを必要に応じて追加することになるでしょう。ただしその場合、サーバーサイドとクライアントサイドでシリアライズ・デシリアライズの実装を一致させる必要があります。 Enum enum(イナム)はscalar型の一種で、特定の値のみを持つ型です。例えば、組み込みscalar型であるBooleanをenumで宣言すると次のようになるでしょう。 enum Boolean { true false

    「GraphQL」徹底入門 ─ RESTとの比較、API・フロント双方の実装から学ぶ|ハイクラス転職・求人情報サイト AMBI(アンビ)
  • リソース指向の設計  |  Cloud API Design Guide  |  Google Cloud

    フィードバックを送信 リソース指向の設計 コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。 この設計ガイドは、デベロッパーが、シンプルで整合性があり、使いやすいネットワーク API を設計するために役立ちます。また、ソケットベースの RPC API と HTTP ベースの REST API の設計を統合する場合にも役立ちます。 RPC API は、多くの場合、インターフェースとメソッドの観点から設計されています。これらが追加されるにつれ、デベロッパーが各メソッドを個別に学習する必要が生じるため、負荷が大きく混乱しやすい API サーフェスになる可能性があります。これによって、膨大な時間がかかり、エラーが発生しやすくなることは明白です。 REST のアーキテクチャ スタイルは、主に HTTP/1.1 で正常に動作するように設計されていますが、この問題への対処に

    リソース指向の設計  |  Cloud API Design Guide  |  Google Cloud
  • API 設計ガイド  |  Cloud API Design Guide  |  Google Cloud

    フィードバックを送信 API 設計ガイド コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。 変更履歴 はじめに これは、ネットワーク API の一般的な設計ガイドです。2014 年以来 Google 内部で使用され、Cloud API やその他の Google API を設計するときに Google が従うガイドです。この設計ガイドは、外部のデベロッパーへの情報提供と、互いの連携作業の効率化のためにここで共有されています。 Cloud Endpoints のデベロッパーには、このガイドは、gRPC API を設計するときに特に役立つことがあり、そのような場合にはこれらの設計原則を使用することを強くおすすめします。ただし、このガイドの使用は必須ではありません。Cloud Endpoints と gRPC はガイドに従わなくても使用できます。 このガイドは、gR

    API 設計ガイド  |  Cloud API Design Guide  |  Google Cloud
  • js STUDIO | JavaScript、jQuery日本語リファレンス

    AngularJS 1.2 ngモジュール ディレクティブ フィルター サービス 型 グローバルAPI ngMockモジュール サービス グローバルAPI AUTOモジュール サービス ngAnimateモジュール サービス ngCookiesモジュール サービス ngMockE2Eモジュール サービス ngResourceモジュール サービス ngRouteモジュール サービス ディレクティブ ngSanitizeモジュール フィルター サービス ngTouchモジュール ディレクティブ サービス このサイトについて リファレンスの翻訳を中心に、JavaScriptに関する情報を取り扱うサイトです。 現在、公開しているJavaScript関連の情報です。 JavaScript Mozilla Developer Networkの内容を翻訳して公開しています。 jQuery jQuery

  • マイクロサービス/API時代のフロントエンド開発

    マイクロサービス/API時代のフロントエンド開発に求められる技術の一つ、Backends For Frontends(BFF)について解説する連載。最終回は筆者の経験に基づいて、3つのBFFアンチパターンと、その回避策を紹介します。

    マイクロサービス/API時代のフロントエンド開発
  • 翻訳: WebAPI 設計のベストプラクティス - Qiita

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? これは Enchant の開発者である Vinay Sahni さんが書いた記事「Best Practices for Designing a Pragmatic RESTful API」1を、ご人の許可を得て翻訳したものです。 RESTful な WebAPI を設計しようとすると、細かなところで長考したり議論したりすると思います。また、他の API に倣ってやってはみたものの、当にそれでいいのか、どうしてそうしているのか分からない、何てことも少なくはないと思います。 この記事では、そのようなハマリどころについて Vinay さん

    翻訳: WebAPI 設計のベストプラクティス - Qiita
  • Web API 設計のベストプラクティス集 ”Web API Design - Crafting Interfaces that Developers Love”

    Apigee Web API Design というを読みました. Web API 設計のベストプラクティスがまとめられている, apigee という API のソリューションを提供している会社がだしているフリーの ebook です. コンパクトに 30 ページほどに読みやすくまとめられています. 以下要点のメモです. 開発者視点 API の目的はアプリケーション開発者 (API 利用者) が可能な限り成功すること. 開発者の視点で設計すること. 書ではそのような API を実現する tips を紹介する. Pragmatic REST REST 原理主義はよくない. RESTafarian たるべからず アプリ開発者の利便性が一番大事. 実利的な REST 設計が求められる それを書では Pragramatic REST とよぶ URL 動詞ではなく名詞 リソースを名詞であらわす.

    Web API 設計のベストプラクティス集 ”Web API Design - Crafting Interfaces that Developers Love”