Web API認証方式のパターン - プログラミング初心者がアーキテクトっぽく語る
Web API認証の混沌 混沌を整理する 認証とはなにか 1. 標準化されたHTTP認証方式 2. APIキー認証 3. Form認証、アクセストークン認証 Web API認証の混沌 認証に成功しないとWeb APIを叩くことはできない。まずは認証である。 認証方法がWebサービスによって異なるというのはよくある話だ。Web APIの認証方式には標準化された様々な認証方式に加えて、実に多様なサービス固有の認証方式が存在する。 よってあるサービスを利用するにはまずそのサービスが提供している認証方式を理解する必要があるがこれがWeb API初心者にとって最初の関門となる。ここで躓いてPostmanをそっと閉じた人も少なくないだろう。 混沌を整理する 認証方式を以下の3パターンに分けてみよう。 標準化されたHTTP認証方式 APIキー認証 Form認証 / アクセストークン認証 まずはこれから取
マイクロサービス間通信における認証認可およびアクセス制御
はじめに 2023年4月に基盤エンジニアとして Ubie に入社しました nerocrux です。主に Ubie の ID 基盤の開発と保守運用を担当しています。 この記事は、2023 Ubie Engineers アドベントカレンダー 5 日目の記事となります。 Ubie では、モジュラモノリスを採用しつつ、マイクロサービスアーキテクチャも採用しており、領域によってサービスを分けて、それぞれの担当チームが開発と保守運用をしています。 クライアントから一つのリクエストを受け取ったあとに、Ubie のバックエンドではリクエストを受け取ったサービスだけがそのリクエストを処理することもあれば、別のサービスにディスパッチし、複数のサービスがひとつのリクエストを処理して結果を返すこともあります。 マイクロサービス間の通信が Ubie の内部で発生したとしても、必ずしも無制限で自由に行われていいわけで
メルカリ ハロの技術スタックとその選定理由 | メルカリエンジニアリング
こんにちは。メルカリ ハロのSoftware Engineer (Engineering Head)の@napoliです。連載：Mercari Hallo, world! -メルカリ ハロ 開発の裏側-の2回目を担当させていただきます。 2024年3月上旬にメルカリ ハロという新しいサービスが公開されました。メルカリ ハロは好きな時間に最短1時間から働ける「空き時間おしごとアプリ」です。 この記事ではメルカリ ハロを作るにあたり、どういった技術スタックやアーキテクチャを選定したのか、さらにその背景と意思決定をご紹介したいと思います。 この記事で得られること メルカリ ハロで採用されている技術スタックやアーキテクチャの全体像 その意思決定の理由とプロセス これから新規サービスを立ち上げるうえでのヒント 主な技術スタック メルカリ ハロで利用されている主な技術スタックは以下のとおりです。 バッ
マイクロサービス化は本当に難しい
はじめに この記事は、AEON Advent Calendar 2023の21日目です🎉 イオンスマートテクノロジー株式会社（通称AST）のCTO室TechLeadチームの@t0doroki_takaです。弊社ではSREチームの発信に勢いがありますが、アプリケーションレイヤーよりの話題も積極的に発信していければと思います。 自分の敗戦の振り返り 以前、大規模ECシステムのリプレース案件に関わった時(そして敗戦したとき)の振り返りです。 今回取り上げるケーススタディは、システム全体(連係するシステム含む)としては段階的移行ではありましたが、主ターゲットとなるシステムは、全EC機能を包括する大規模なシステムで、それをフルスクラッチでリプレースするものでした。 巨大なモノリス構造であったため、マイクロサービスアーキテクチャに移行することで、サービス提供のアジリティを確保することが目的の一つでし
ハッキングAPI
Web APIは近年急速に利用が拡大しています。APIの呼び出しが全Webトラフィックの80％以上を占めるほど、Webサービスに欠かせない技術となっている一方で、Web APIに対するサイバー攻撃も急増しており、そのセキュリティ対策はあらゆる組織で重要な課題となっています。 本書の目的は、Web APIの基本をしっかり押さえ、脆弱性が存在しないかどうかテストする方法を示すことです。攻撃者（APIハッカー）の視点から、あらゆるAPI機能と特徴を活用するための知識を学ぶことで、これから起こり得る情報漏えいの危機を防ぐことができます。まず、WebアプリケーションやWeb API脆弱性の種類などの基礎知識を学んだのち、実際に検証用ラボを構築しながら、脆弱性の調査方法、ツール、さまざまな攻撃手法などを、実践的に解説していきます。Webアプリケーションで最も一般的なAPI形式であるREST APIのセ
ChatGPT APIを使ったLineBotの作り方を、人格の与え方まで完全解説【プログラミング不要】｜ChatGPT研究所
元々書いてあるコードを全て削除したのち、以下のコードを貼り付けます。 function doPost(e) { const props = PropertiesService.getScriptProperties() const event = JSON.parse(e.postData.contents).events[0] let userMessage = event.message.text if (userMessage === undefined) { // スタンプなどが送られてきた時 userMessage = 'やあ！' } const requestOptions = { "method": "post", "headers": { "Content-Type": "application/json", "Authorization": "Bearer "+ prop
Server side Kotlin で社内APIを開発した〜使い方（入門編）便利Tips〜 - GMO Research & AI Tech Blog
はじめまして。システム部の岡崎です。 現在はCTOオフィスでビックデータのデータ集めに関する基盤整備や、アプリケーションの開発を担当しています。 タイトルにある通り、今日はServer side KotlinでAPIを開発した話について、そして自分が実際にKotlinを使っていて便利だと感じたことや、発見したことについて説明していこうと思います。 Kotlinを使うことになった経緯 社内利用のAPIを作ることになり、 spring-boot + myBats + Kotlin を提案したところ見事採用されました。 なぜKotlinを使ってみようと思ったかというと。 そもそもWeb APIを作成することになった際、下記3つの選択肢がありました。 Cake PHPJava Spring-bootKotlin 以前 Spring-boot＋myBatis+Java でバッチの開発をしたときに、S
Amazon Elasticsearch Service の認証・認可に関する面倒くさい仕様をなるべくわかりやすく説明する - 無印吉澤
はじめに 最近、仕事で Amazon Elasticsearch Service（以下、Amazon ES）を本格的に使う機会があって、認証周りの仕様で苦労させられました。 Elasticsearch を本格的に使う人は、自分で Elasticsearch クラスタを立てたり、Elastic Cloud を使ったりしてしまうからか、Amazon ES 周りの情報は意外と見つかりませんでした。せっかくなので、今回の記事では、自分が Amazon ES を使うにあたって調べた情報をまとめてみます。 はじめに いろいろな Elasticsearch Amazon ES の基本 Amazon ES が提供する認証・認可 パブリックアクセスの場合 VPC アクセスの場合 IP アドレス以外の認証・認可方法は AWS 署名しかない Elasticsearch API へのリクエストを AWS 署名する
ISUCON9 予選を全体1位で突破しました
9月8日(日)に開催された ISUCON9 予選の2日目に1人チーム「 nil 」として参加し、全体1位となり本選出場が決まりました。 最終スコアは 52,440 ｲｽｺｲﾝ (ベストスコアは 53,460 ｲｽｺｲﾝ) でした。 このエントリーでは主に参加するまでにやってきたことと、当日やったことについて書こうと思います。 参加するまでにやってきたこと# 練習 (去年)# ISUCON には去年の ISUCON8 で初めて参加し、今年で2回目です。 去年は ISUCON8 に向けて毎週のように過去問の練習をしていました。 1年以上前の記憶ではありますが、今年はあまり練習することができなかったので、この経験や知恵が今回の優勝にも影響したと考えています。 練習 (直前)# 今年は他のことで忙しく ISUCON の練習をする時間が確保できませんでした。 そのため練習できたのは5日(木)から前日
Swaggerで定義したAPIドキュメントとAPIレスポンスの差異をなくす - Qiita
はじめに VASILYでは、API開発を始める前に、Swaggerを用いてAPIドキュメントを作成しています。 APIドキュメントを作成した後、実際のAPIレスポンスを修正したがドキュメントの更新を忘れ、ドキュメントの定義と実際のレスポンスの間に差異が生じてしまうということがありました。 そこで、今回はcommitteeというgemを用いて、Swaggerで定義したAPIドキュメントと実際のAPIレスポンスとの差異を検知する方法をご紹介します。 committeeとは committeeは、実際のAPIリクエストやレスポンスがスキーマ定義にそっているかをチェックすることができるgemです。 Rackのミドルウェアとして動作します。 バージョン2.0からはJSON Schemaだけでなく、OpenAPI2.0(Swagger)もサポートされるようになったため今回はこちらのgemを使用します。
トラブルシュート時などの現状ざっくり把握のためのAPI一覧まとめ (Elasticsearch) - はてだBlog（仮称）
検索アプリエンジニアの立ち位置視点で、Elasticsearchのモニタリング全般やテーブル構造(テーブルではありませんが...、たとえ話として）、インデックスに抱えているデータをマシンルームのような制限がある場所で（※そのような状況が良いかは別に置いておいて）、コンソール・ターミナルでカタカタ調べる場合に役立つElasticsearchのビルトインのエンドポイント(APIといった方が良いのかな?)をまとめました。 公式Rをある程度なぞった程度にすぎませんし、他のチートシートやテック記事に比べると深さ不足ですが、 しばしば担当を離れていた検索サイトで「検索の当たり方が悪い」というクレームが発生して、レスキューに入ることになった。 *（それが良いか悪いかはともかく）Elasticsearchにしばらくふれておらず、調査の勘所を思い出すにも、急遽駆けつけてくれと無理筋オーダーで現地に向かうこと
Goで書くClean Architecture API - Qiita
Enterprise Business Rules ビジネスルールの為のデータ構造を持ったオブジェクト。 データの実態を表す場所。 Application Business Rules ビジネスルールを操作する場所。 つまりこのアプリケーションで何ができるかを実践します。 Interface Adapter 外部からの入力、データの永続化、表示を担当する場所 Frameworks & Drivers Webフレームワーク、DB操作の実際に担うソース、 フロントエンドのUIなどがここに所属しています。 外側のレイヤーの要素を直接参照してはならない 上記の図におけるこの矢印は依存を表しており、 内側のレイヤーから外側のレイヤーの要素への依存を禁じます。 ここでいう依存とは要素(構造体、変数など)への直接参照をさせないということです。 では外側のレイヤー要素を参照せざる得ないは、どうするのでしょ
シンプルさとパフォーマンスを両立した API 設計と実装の一例 - HeartRails Tech Blog
こんにちは、エンジニアの村田です。今回はシンプルさとパフォーマンスを両立した API を作るためにはどうすればよいのかについて述べていきます。 背景 いままで API サーバーを作ってきて、シンプルな API にすればパフォーマンスが犠牲に、パフォーマンスを優先すれば実装が複雑になって保守が大変になるということを経験してきました。具体的には、 関連リソースの Entity が何重にもネストしていたり、同じリソースに一覧用、詳細用などの Entity があり実装、保守が大変 1. の問題を解消するためにシンプルな API にする 2. では N+1 の問題がありパフォーマンスが悪い 1. 2. の問題を解消するためにリソースの Entity はシンプルにしつつ、パラメーターで関連リソースを指定すると関連リソースの Entity を埋め込んで返すようにする 4. だと関連リソースの権限管理やペ
［速報］GitHub、見られてはいけないコード中のアクセストークンを発見し通知してくれる「Token Scanning」発表。GitHub Universe 2018 － Publickey
［速報］GitHub、見られてはいけないコード中のアクセストークンを発見し通知してくれる「Token Scanning」発表。GitHub Universe 2018 クラウドサービスが充実してきたことで、コードからクラウドAPIを呼び出して利用することが一般的になってきました。クラウドAPIを呼び出す際には、適正な呼び出し権限を持つことを示すため、あるいは呼び出す側を特定して課金するなどの目的でアクセストークンを用いることがあります。 アクセストークンは第三者に知られないように安全に管理し利用する必要がありますが、何らかの原因でアクセストークンがコード内にそのまま記述されてそのコードがGitHubなどで公開された結果、悪意のある第三者に使われ、アクセストークン本来の持ち主に膨大な利用料金が請求される、といった事故がしばしば起きています。 GitHubはこうした事故を防ぐため、コード内に記
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
AIとAPIで開発を加速！Postman v11リリース
Backend エンジニア視点からの GraphQL / GraphQL from a perspective of backend engineer
APIシナリオテストツールとしてのrunn / 4 API testing tools
モノリシックRailsアプリケーションを モジュラモノリスへ移行している noteの事例
真のREST
Best practices in web API client development #RubyKaigi
