エンジニアお茶会 2020/08/19 pastak.icon @pastak この発表のゴール 現代のウェブブラウザの目指している方向性について紹介する モダンブラウザで使える最新の面白便利APIを紹介する ちゃんと仕様に入りそうなもの(Googleの力技で…も含む) (前半の各ベンダの話はpastak.icon個人の見解を含みます) 次ではない フロントエンドなんでも相談室 前提知識のコーナー "WebAPI"とは何を指すのか、標準化について ECMAScript Ecma InternationalにてECMA-262という規格番号 ほぼLiving Standardという雰囲気もあるけど、年に1回タグが付く ES2020: ECMAScript® 2020 Language Specification 最新の様子: https://tc39.es/ecma262/ Array、Nu
::: message info これは[フィヨルドブートキャンプ Advent Calendar 2022 Part.1](https://adventar.org/calendars/7760)の25日目の記事です。 昨日の記事は:@shujiwatanabe:shujiwatanabeさんの[質問しながら出来るようにしていく](https://shu91327.hatenablog.com/entry/2022/12/24/091025)と:@saeyama:saeyamaさんの[Rails/Vue 編集時に画像をD&Dで入れ替えした時のActive Storageの保存方法](https://saeyama.hatenablog.com/entry/2022/12/24/000123)でした。 ::: ↓こういうのを職人が丹精込めて一つ一つ手作りする時代は終わりました。 ```sh
マイクロサービスにおけるWeb APIスキーマの管理 ─ GraphQL、gRPC、OpenAPIの特徴と使いどころ マイクロサービスにおける通信方式の選択について、おおた(ota42y)さんが、GraphQL・gRPC・OpenAPIといった主なWeb APIスキーマの管理の利点と使い分けを解説します。 近年流行しているマイクロサービスアーキテクチャにおいては、「どういった通信方式を選ぶか」が開発の効率やサービスの信頼性、パフォーマンスを大きく左右します。この記事では、GraphQL・gRPC・OpenAPIそれぞれの利点と適切な使い分けについて解説します。 マイクロサービスにおけるWeb API管理の重要性 Schema First DevelopmentとWeb API 人ではなくプログラムが処理できるよう管理する Web APIのインタフェース定義手法の比較 OpenAPI ─ R
サマリ ハッキングAPI―Web APIを攻撃から守るためのテスト技法(2023年3月27日発売)を読んだ。本書は、Web APIに対するセキュリティテストの全体像と具体的なテスト方法を記載している。ペンテスターは、APIの検出、APIエンドポイントの分析、攻撃(テスト)を行う必要があり、そのために必要な情報がすべて記載されている。また、実習のためのツールと「やられサイト」を複数紹介し、具体的なトレーニング方法を解説している。単にツールやサイトの使い方の説明にとどまらず、本格的なペネトレーションテストの考え方を説明している。 本書の想定読者はAPIのペネトレーションテストを実施するペンテスター及びペンテスターを目指す人であるが、API開発者やウェブアプリケーション脆弱性診断員にとっても有益な内容を多く含む。 重要事項説明 本書の監修者の一人(洲崎俊氏)と評者は知人関係にある 評者が読んだ書
はじめに Vue.jsを使用したアプリケーションでのWeb API呼び出しのデザインパターンについて調べてみました。 しかし検索して出てくるチュートリアルやサンプルは、コンポーネント内でaxiosをインスタンス化していたり、Vuexの中でaxiosを使用するというサンプルがほとんどでした。 しかし実際のプロダクトでこれをしてしまうと コンポーネント内でAPIアクセスの直書きによって単体テストが困難に Vuex(actions)の肥大化(使い回さない処理はStoreに記述しないほうがいいとする文献もある) API通信部分をPureJSでモジュール化しても依存度がイマイチ下がらない(コンポーネントでモジュールをインポートするため)。 などなど問題になることが多そうでした。 ある日、Jorge氏が投稿した「Vue API calls in a smart way」という記事にたどり着きました。
プレゼンテーションレイヤ、いわゆるフロントエンドがクライアントサイドで実装・実行されるアーキテクチャ (注 1) において、管理画面/管理機能をあとから追加する際にどのような実装パターンがあるのかを整理してみます。 注 1: Presentation Domain Separation の実践の中でも、物理的にプレゼンテーションロジックとドメインロジックを分離しているアーキテクチャです。 用語の整理 プレゼンテーションレイヤ 三層アーキテクチャにおける、システムの利用者へユーザインターフェイスを提供する層です。本記事では"フロントエンド"とほぼ同義で使います。 OSI 参照モデルの第六層ではないです。 バックエンド Web API とは プレゼンテーションを持たない Web API (HTTP プロトコルを用いてネットワーク越しに呼び出すアプリケーション) とします。 プレゼンテーションレ
サーバーレスアーキテクチャを基礎から復習したかったです。手を動かしたい派なので初心者向けのハンズオンをやってみました。なにを復習したら良いのかはやってみてから考えることにしました。 以下の構成を手を動かして作ります。 画像引用: ハンズオンのアンケート回答後にダウンロードできる資料より やってみた感想 2019年に収録されたハンズオン動画のため一部マネージメントコンソールのUIに変更は見られるものの構築する上では支障はありませんでした(2021年11月現在) API Gateway プロキシ統合のLambda(Python)と、SDKを使い他のAWSサービスの呼び出しを試せる 以下のサービスの連携を簡単に体験したい初心者にオススメ API Gateway Lambda Translate DyanamoDB ハンズオンを完走するまでの所要時間は約1時間30分でした ハンズオン記事のリンク
TL;DR エラーハンドリングを行う目的 エラーハンドリングが適切に行われているとどう嬉しいか 1. エラーの発生原因が分かる 2. レスポンスステータスを型安全に出し分けることが可能になる どうエラーハンドリングを行うのか 実装方法 エラー型の定義で気を付けるべきポイント なぜanyhowを利用しないのか エラーハンドリングを行う上で持っている課題感 Drawer Growth グループ バックエンドエンジニアの中野です。今回は、私が所属するチームで gRPC API を開発する際に実践している Rust でのエラーハンドリングについて紹介していきます。 TL;DR エラーの発生原因がわかるようにエラー型を定義することが大切。 anyhow は使わずに自前のエラー型を定義して利用する。 エラーハンドリングを行う目的 そもそもなぜエラーハンドリングを行う必要があるのでしょうか。私が所属する
W3Cの WebAssembly Working Groupは、Webブラウザ上でネイティブコードに近い実行速度で高速に実行できるバイナリフォーマット「WebAssembly」の仕様が勧告に到達したことを発表しました。 今回勧告になったのは、WebAssemblyに関連する3つの仕様です。 1つ目はWebAssemblyのバイナリファイルを実行する仮想マシンの仕様を定義した「WebAssembly Core Specification」。これは一般的なマイクロプロセッサの動作を模倣するような作りにすることで、WebAssemblyのバイナリファイルでプロセッサのネイティブコードに近い実行速度を実現するようになっています。 2つ目の「WebAssembly Web API」は、さまざまなプラットフォームでWebAssemblyを利用可能にするため、WebAssemblyバイナリファイルのシリ
先日登壇したイベントにて、仕事で協業したモバイルエンジニアから「Web APIのドキュメントに使われ方の想定が添えられていてありがたかった」とフィードバックをもらった。 具体的にはX post (以下、tweet) に添付した画像のような感じで、Web API (以下、API) が呼び出される画面・タイミングの想定、レスポンスの使われ方の想定などをUIのスクショとともに記述する、というもの。 API設計時にこういう使われ方の想定を添えると認識揃えやすくてありがたい、とモバイルエンジニアに喜ばれました#B43_techtalk pic.twitter.com/XLB3g6fCLZ— ohbarye (@ohbarye) 2023年8月3日 他にもこんなのとか。 APIレスポンスの使われ方の想定を書いているようす このことについて思ったよりもイベント内外で反響があったので書く。 ドキュメントの
MDNのWeb APIリストから、便利で、しかし普段のサービス開発ではあまり使われていない可能性のあるAPIを8個選びご紹介します。これらのAPIはあまり知られていないかもしれませんが、特定の状況や要件に対して非常に有効であることがあります。 Beacon API Beacon APIは、非同期でブロッキングしないリクエストをWebサーバーに送信するために使用されます。このリクエストはレスポンスを期待しないため、XMLHttpRequestやFetch APIを使ったリクエストとは異なりページがアンロード(ウェブページがユーザーによって閉じられるか、別のページに移動する際)される前にブラウザがビーコンリクエストを開始し、それを完了させることを保証します。 主な使用例としては、クライアント側のイベントやセッションデータをサーバーに送信するために使用されます。このAPIは、navigator.
「Mix Leap Study」はヤフーの独自技術や業界の最先端テクノロジーに触れる勉強会。第59回は「React とその仲間たち」と題して、より実践的にReactを使うための仲間たちにも注目。株式会社Gemcookの藤本卓哉氏が、プロジェクトにGraphQLを採用してみた経験から、いい点、悪い点を語ります。 React + GraphQLで社内の負債を解決した話 藤本卓哉氏:みなさん、こんばんは。ジェムクックの藤本です。『React + GraphQLで社内の負債を解決した話』というタイトルでお話ししたいと思います。よろしくお願いします。 まず簡単にプロフィールです。藤本卓哉と言います。去年(2019年)30歳になって、今年(2020年)31になります。会社の代表兼エンジニアをやっています。会社の代表といったら、経営ガッツリやっているんかなって言われがちなんですけど、僕けっこうエンジニア
この記事はPython Advent Calendar 2022 カレンダー2の3日目です。昨日はtttakehさんのじゃんけん画像を分類してみたでした。 はじめにこんにちは。TIG DXユニットの村上です! さて、私の所属しているプロジェクトではバックエンドシステムに主にGo言語を用いており、Go言語によるWebAPIを構築しています。 例えばLambdaとGoを使ったサーバーレスWebAPI開発実践入門など、Future Tech Blogには多くのノウハウが投稿されていますので是非ご覧になっていただければと思います。 今回はGo言語ではなくPythonでWebAPIを構築しました。その際にOpenAPI Generatorが便利だったのでご共有します。 OpenAPI GeneratorOpenAPI GeneratorはAPIリクエストやレスポンスの内容を定義し、それを元にプログラ
APIというとWeb APIのことを指すようになってしばらくたちますが、こういう場合WebじゃないほうのAPIを指すレトロニムができるはずなんですよね。 例えばこのエントリのタイトルではローカルAPIという言葉を使ったけど、埋め込みAPI、組み込みAPIという言い方も可能な気はして、そしてどれもしっくり来ない。シェアドライブラリを考えると埋め込みAPI / 組み込みAPIというのは不適切でローカルAPIが適切な気がするけど、違和感が大きい。 元々でいうと、アプリケーションプログラマがなんらかミドルウェアなどを使うための入り口というのはAPIで、SQLもAPIのひとつだったりした。 C.J.DateとCodd博士の「The relational and network approaches: Comparison of the application programming interfac
builderscon tokyo 2019 で「Web API に秩序を与える Protocol Buffers」というタイトルで発表した資料です。 Protocol Buffers を利用して Web API の Schema 管理をするという観点で、豊富な実例とともにその手法やメリット・デメリットについて話しました。 cf. https://builderscon.io 追記: 61ページ目で Protocol Buffers を利用する際の注意点として後方互換性が壊れるケースの話をしましたが、自分たちが経験したのは gRPC + grpc-gateway 構成特有のケースだったので記述を修正しました。
本書はエンジニアのための情報共有コミュニティ「Zenn」で中村翔さんが公開されている人気コンテンツ「FastAPI入門」を元に書籍化。Python3.11への対応、コラムの追加、本番環境での運用を想定したAWS・GCPへのデプロイ方法について追記するなど、大幅にパワーアップした内容となっています。 FastAPIはDjangoやFlaskに並んで人気が高いPythonのWebフレームワークです。コードを書くとSwagger UIが自動生成される、型安全、高速という優れた特長もあって実際の開発現場で利用されることも増えています。 本書ではそんなFastAPIの使い方を、ToDoアプリの作成を通じて学べます。特に、以下の点にこだわって解説しています。 DB接続にもasync/awaitを利用 Dockerによるクリーンな環境構築 スケーリングを考慮したディレクトリ構成 FastAPIが気になっ
TL;DR Ramen APIを作った REST API、GraphQLにも対応している 登録・認証いらず、完全無料 プロトタイピングやテストに使える 店ごとのラーメン写真が手に入る 現在、26店舗登録されている 例えば、Reactを勉強する時に使う GitHubリポジトリにてコンテンツを追加できる 詳しくはGitHubリポジトリを見てもらいたい Base URL: // GET https://ramen-api.dev/shops/yoshimuraya?pretty { "shop": { "id": "yoshimuraya", "name": "吉村家", "photos": [ { "name": "yoshimuraya-001.jpg", "width": 1200, "height": 900, "authorId": "yusukebe", "url": "https:
どうも、まさとらん(@0310lan)です! 今回は、誰でも簡単に独自APIの開発から一般公開までを完結できる無料のWebサービスをご紹介します。 ビジュアルエディタを採用した構築方法なので直感的に理解しやすく、そのまますぐに公開まで可能なのが特徴です。APIを利用したWeb開発やJamstackなどにご興味ある方はぜひ参考にしてみてください! 【 Canonic 】 ■「Canonic」の使い方 それでは、「Canonic」をどのように使えばいいのかを詳しく見ていきましょう! まずはサイトのトップページから【Signup】ボタンをクリックして無料のユーザー登録をしておきます。 GoogleやFacebookのアカウントから簡単に登録ができるようになっていますが、今回はGitHubのアカウントを利用して登録します。 初回のみ、GitHubアカウントとの連携画面が表示されるので認証しておきま
docker-compose.yml version: '3.6' services: app: image: openjdk:15 ports: - 8080:8080 tty: true volumes: - ./server:/srv:cached working_dir: /srv OpenJDK | DockerHub https://hub.docker.com/_/openjdk JDK Project Releases | OpenJDK 指定できるバージョン情報はここ http://openjdk.java.net/projects/jdk/ Gradleプロジェクト作成 今回も Spring Initializr というサイトで作ってしまいます。 Spring Initializr https://start.spring.io/ 前回の記事との違いは特にないです。 入
本記事の目的 機械学習の推論web APIの典型的な構成を紹介します。必ずしもWEBの知識や機械学習の知識はなくても読める内容だと思います。(実装例は除く) 紹介する構成は、業務でいくつかの機械学習モデルの推論web APIをたてた経験からきていますが、あくまでも個人的見解なので、こっちのほうがいいよーってのがあればコメントで教えていただけると幸いです。 実装例ではweb frameworkは非同期処理の扱いやすさ、実装のシンプルさの観点からFastAPIを使います。 目次 機械学習の推論web APIの構成 実装例 1. 機械学習の推論web APIの構成 本記事では、2つのパターンを紹介します。 注) まず、共通部分の説明をします。機械学習の知見が必要なのは基本的に共通部分だけです。もし、機械学習に詳しくない or webに詳しくない場合は、共通部分と後述の部分で役割を分担できるので、
WebOTP API は、特別な形式の SMS メッセージの受信時にワンタイムパスワードを生成することで、電話番号がユーザーのものであることを検証する方法を提供します。 電話番号はアプリケーションがユーザーを識別する方法としてよく使用され、番号がユーザーのものであることを検証するため、SMS がよく使用されます。通常のシナリオでは、ユーザーにワンタイムパスワードを含むメッセージが送信されます。そして、ユーザーはこのパスワードを、番号がユーザーのものであることを検証するフォームにコピペしなければならないでしょう。 WebOTP API は、アプリケーションがパスワードをコピペなしで自動で受信して検証することを可能にし、この手続きで生じるイライラを解消します。
こんにちは。LINEヤフー株式会社で自然言語処理の開発を担当している牧野です。 今回は、Yahoo!デベロッパーネットワークから公開しているテキスト解析 Web API の「日本語形態素解析」で使えるようになった追加機能のユーザ辞書を紹介します。このユーザ辞書を使うと、自分だけのオリジナルの辞書で独自の解析が可能です。 また今回は、ユーザ辞書機能を工夫して使った簡易感情判定についても紹介します。 日本語形態素解析 Web API でできること 最初に、日本語形態素解析 Web API について簡単に紹介します。 日本語形態素解析 Web API 日本語形態素解析 Web API は、日本語文を形態素に分割し、品詞の推定や活用処理、読みを付与することができます。形態素とは、日本語として意味を持つ最小単位のことです。「辞書に載っている単語」程度のイメージで捉えていただけると良いでしょう。 たと
セキュリティ脆弱性診断などでたまに CSRF について指摘されることがあります。 今まではトークン発行して対応すれば良いんでしょ? と思ってましたが、SPA のように非同期通信が前提の場合はどう対処するべきなんだろう、と疑問が出たりしたので、調べてみた結果をまとめてみました。 CSRFとは Cross Site Request Forgeries(クロスサイトリクエストフォージェリ)の略で、 サービス利用者の正規権限を利用して、意図しないタイミングでサービスの機能を実行させる攻撃手法のことを指します。 2005年に mixi 日記で発生した「ぼくはまちちゃん」で一躍有名になりました。 大量の「はまちちゃん」を生み出したCSRFの脆弱性とは? - ITmedia エンタープライズ CSRF が発生する原因 サービスの機能を実行するプログラムへのリクエストの検証が権限情報のみであった場合に発生
この記事では、シングルページアプリケーション開発での Web API 設計について書いていきます。 ここで言う「エンドポイント」とは、HTTP メソッドと URL の組み合わせです。また、本記事で扱うのは、いわゆる REST API と呼ばれるタイプの Web API です。最近は GraphQL が台頭してきていますが、まだ現場では REST タイプの API を扱うことがほとんどでしょう。 API 設計は大きく2つの側面があります。エンドポイント定義と、リクエストおよびレスポンスメッセージの JSON 定義です。本記事では、特にエンドポイント定義の設計について取りあげます。なぜなら、どちらかというと、エンドポイント定義のほうが、これから SPA 開発にチャレンジする方にとって、難しさがあるように感じるからです。 Web API とは 何を API にするのか まず、そもそも何を API
マイクロタスクは、それを作成した関数やプログラムが終了した後、 JavaScript 実行スタックが空の場合にのみ実行され、ユーザーエージェントがスクリプトの実行環境を動かすために使用しているイベントループにコントロールを返す前に実行される短い関数です。 このイベントループは、ブラウザーのメインイベントループか、ウェブワーカーを駆動するイベントループのどちらかです。これにより、他のスクリプトの実行を妨げるリスクなしに与えられた関数を実行することができ、同時に、ユーザーエージェントがマイクロタスクによって行われるアクションに反応する機会を得る前に、マイクロタスクが確実に実行されるようにします。 JavaScript のプロミスと変更監視 API は、どちらもコールバック実行にマイクロタスクキューを使用しますが、現在のイベントループパスがラップされるまで作業を遅延する能力がある他の場合がありま
Have you ever wondered how web compatible Deno is? Probably not, but I did today. To answer that question, I am writing this blog post: I’ll list and explain every single web API implemented in Deno. Get yourself something to drink, because this is going to take a while to go through. Before we get into it though, I just want to set some ground rules: I am not including any JS language features. O
チームでのWeb API開発において、進行を妨げる要因は様々な形で噴出します。 「フロントはバックエンドのAPI実装待ちなので動けません...」「ドキュメンテーションのコストが重い...」「ドキュメントと実装が全然違うので参考にならない...」 また、APIスキーマ設定が不十分だと、ビジネスドメインの最低原則やクライアント側のニーズを理解せずに、バックエンド都合のAPIがそのまま実装される危険性もあります。 そうした問題を解決すべくSchema Driven Developmentと呼ばれる開発手法が生まれました。 Schema Driven Developmentとは? Schema Driven Development(以下SDD)とはチームにおけるWeb API開発フローを改善する開発手法の一つです。スキーマ駆動開発やSchema First Developmentとも呼ばれています
いつもYahoo! Open Local Platform(YOLP)をご利用いただきありがとうございます。 この度誠に勝手ながら、2020年10月31日をもちまして、以下のWeb API・SDKの提供を終了いたします。 ■終了対象API・SDK Yahoo! JavaScriptマップAPI Yahoo!スタティックマップAPI Yahoo! iOSマップSDK Yahoo! AndroidマップSDK 経路地図API ■終了予定日 2020年10月31日(土) ※終了予定日以降、対象のYOLP Web API・SDKの動作は保証致しかねます。ご了承ください。 代替サービスなどの詳細はこちらをご確認ください。 提供内容の見直しにより今回のご案内となりますが、ご利用中の皆様にはおわび申し上げますとともに、これまでのご愛顧に感謝いたします。 今後ともYahoo!デベロッパーネットワークをよろ
Supershipの名畑です。近頃のアニメのOPとEDは本当に内容に寄せてきて素晴らしいなとマッシュル-MASHLE-のOPとEDを見ながら思います。 はじめに 前回の記事「Stable Diffusionでの画像生成をPythonとWeb APIで実装してみた記録」ではテキストからの画像生成モデルであるStable Diffusionでのアカウント作成から画像生成までを記録に残しました。 今回はStable Diffusion記事の第二弾です。 人物の画像生成をしていると「同じ顔を別の表情にしたい」というケースがあります。 それを実現するには同一人物の画像を大量に揃えて学習させるというのが本筋でしょうか。あるいは私が知らないだけで、用意されたモデルやサービスを使えばある程度やりたいことがやれるのかもしれません。MidjourneyやNovelAIやControlNetなど、画像生成では色
更新(2019年10月30日)初回投稿から3ヶ月経ちました。 この3ヶ月で新しく得た知見を基に、内容を一部アップデートしました。 今回やることGoのディレクトリ構成についていろいろと調べる中で、 こちらの資料 がとても分かりやすかったので、 今回はこちらを参考にGoでWeb APIを作っていきたいと思います。 加えて、本プロジェクトでは、DDD と レイヤードアーキテクチャー を取り入れます。 (内容はほぼレイヤードアーキテクチャになってしまいましたが…) DDD については、「DDD を Go とレイヤードアーキテクチャでやるなら、こんな感じかな?」という個人の見解レベルです。 パッケージ構成の参考になれば幸いです。 (ですので、ドメインモデルは重度のドメイン貧血症に陥っていますw) 釣りタイトルみたいになっちゃっててすみません🧝♀️ 環境MacOS Mojave 10.14.6Go
Web API認証の混沌 混沌を整理する 認証とはなにか 1. 標準化されたHTTP認証方式 2. APIキー認証 3. Form認証、アクセストークン認証 Web API認証の混沌 認証に成功しないとWeb APIを叩くことはできない。まずは認証である。 認証方法がWebサービスによって異なるというのはよくある話だ。Web APIの認証方式には標準化された様々な認証方式に加えて、実に多様なサービス固有の認証方式が存在する。 よってあるサービスを利用するにはまずそのサービスが提供している認証方式を理解する必要があるがこれがWeb API初心者にとって最初の関門となる。ここで躓いてPostmanをそっと閉じた人も少なくないだろう。 混沌を整理する 認証方式を以下の3パターンに分けてみよう。 標準化されたHTTP認証方式 APIキー認証 Form認証 / アクセストークン認証 まずはこれから取
更新APIの難しさ ネットワークの向こう側にあるリソースを更新するのは、単純なTCP/IPの仕組みでは難しい。その上に構成されたシンプルなプロトコルである単純なHTTPで実現しようとすると、以下に示すような箇所でエラーの発生可能性があり、双方で等しく検知することができないケースが存在し、同期的なリカバリが困難である。 エラーの発生箇所 1. クライアント→サーバの接続エラー 2. クライアントからリクエスト送信したがサーバに届かない。 3. サーバが不完全なメッセージを受信した。 4. メッセージがサーバの処理キューに入らない。 5. サーバで処理が正常に完了しない。 6. サーバからレスポンスを返そうとしたが接続が切れている。 7. サーバからレスポンスを返したが、クライアントに届かない table:エラー検知 クライアント サーバ ① コネクションタイムアウト,... 検知不能 ② ソ
用途がイマイチよくわからない。 風変わりなWeb APIをまとめてみました。 ジョーク系 Official Joke API ランダムなジョークを教えてくれるAPI。 フリ(setup)とオチ(punchline)にキーが分かれているところがニクい。 https://official-joke-api.appspot.com/jokes/random icanhazdadjoke 「Dad Joke」(親父ギャグ)を教えてくれるAPI。 検索したり画像で取得したりもできます。 curl -H "Accept: application/json" https://icanhazdadjoke.com/ {"id":"W018xscFIe","joke":"Have you heard of the band 1023MB? They haven't got a gig yet.","stat
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く