作りすぎない技術 - API時代の開発努力の在り方について考える / Thinking about the state of development efforts in the API eraPresentation Slides for 開発生産性Conference 2024 Session title: 作りすぎない技術 - API時代の開発努力の在り方について…
B/43カード決済システムのしくみ（前編） - inSmartBank
こんにちは！ スマートバンクでソフトウェアエンジニアをしている uribou です。 今回は B/43 のカード決済システムのしくみについて解説しようと思います！ B/43 では Visa のプリペイドカードを発行しており、普段はあまり触れる機会のないカード決済の業務やシステムの裏側を知ることができます。 前編ではカード決済システムの一般的なしくみ、後編では B/43 での詳細な実装方法について解説していこうと思います！ カード決済の基本的なしくみ スマートバンクは Visa のプリペイドカードを発行しているカード発行会社になります。 このカードは、世界中どこの Visa 加盟店でも利用できますが、これは Visa が運営している決済ネットワークに B/43 のシステムを繋ぎこむことで実現しています。 カード決済システムを作るためには、Visa が要求する業務やシステムを構築し、Visa
令和時代の API 実装のベースプラクティスと CSRF 対策 | blog.jxck.io
Intro CSRF という古の攻撃がある。この攻撃を「古(いにしえ)」のものにすることができたプラットフォームの進化の背景を、「Cookie が SameSite Lax by Default になったからだ」という解説を見ることがある。 確かに、現実的にそれによって攻撃の成立は難しくなり、救われているサービスもある。しかし、それはプラットフォームが用意した対策の本質から言うと、解釈が少しずれていると言えるだろう。 今回は、「CSRF がどうして成立していたのか」を振り返ることで、本当にプラットフォームに足りていなかったものと、それを補っていった経緯、本当にすべき対策は何であるかを解説していく。 結果として見えてくるのは、今サービスを実装する上での「ベース」(not ベスト)となるプラクティスだと筆者は考えている。 CSRF 成立の条件 例えば、攻撃者が用意した attack.examp
CI/CDがあたりまえの今の時代にAPIテスティングツールに求められていること / CI/CD Test Night #7
https://testnight.connpass.com/event/311263/
About - Rust API Guidelines
This is a set of recommendations on how to design and present APIs for the Rust programming language. They are authored largely by the Rust library team, based on experiences building the Rust standard library and other crates in the Rust ecosystem. These are only guidelines, some more firm than others. In some cases they are vague and still in development. Rust crate authors should consider them
RFC 7807 - Problem Details for HTTP APIs 日本語訳
RFC 7807 - Problem Details for HTTP APIs 日本語訳 原文URL : https://datatracker.ietf.org/doc/html/rfc7807 タイトル : RFC 7807 - HTTP APIの問題の詳細 翻訳編集 : 自動生成 [要約] RFC 7807は、HTTP APIの問題の詳細を提供するための仕様であり、エラーレスポンスの標準化を目的としています。この仕様は、APIの開発者とクライアント間のコミュニケーションを改善し、問題の特定と解決を容易にすることを目指しています。 Internet Engineering Task Force (IETF) M. Nottingham Request for Comments: 7807 Akamai Category: Standards Track E. Wilde ISSN:
RESTful のウェブ API 設計で避けるべき 6 つのよくあるミス | Google Cloud 公式ブログ
※この投稿は米国時間 2022 年 12 月 1 日に、Google Cloud blog に投稿されたものの抄訳です。 オンラインで、組み立て式のテーブルを注文したとします。ところが、パッケージを開けてみると、組立説明書が入っていません。完成品がどんなものかはわかっていても、それぞれのパーツをどう組み立てればいいのか、まるでわかりません。設計が不十分な API を使うコンシューマ開発者も、同じような経験をしているといえます。適切に設計された API なら、容易に見つけ、検索してアクセスし、使用することができます。高品質の API は、コンシューマ開発者がアイデアをひらめき、新しいユースケースを作り上げる手助けになってさえくれます。 もちろん、API 設計を改善する方法はあります。たとえば、RESTful のプラクティスに従うなどです。しかし、お客様が知らず知らずのうちに、ちょっとした不便
クラウド アプリケーションのベスト プラクティス - Azure Architecture Center
これらのベスト プラクティスは、信頼性が高く、スケーラブルで、セキュリティで保護されたアプリケーションをクラウドで構築するのに役立ちます。 効率的で信頼性の高いシステム、メカニズム、アプローチを設計および実装するためのガイドラインとヒントを提供します。 多くの場合、Azure サービスで使用できるコードの例も含まれています。 これらのプラクティスは、ホストが Azure であるか別のクラウド プラットフォームであるかにかかわらず、すべての分散システムに適用できます。 プラクティスのカタログ 次の表は、さまざまなベスト プラクティスを示しています。 「関連する重要な要素やパターン」列には、次のリンクが含まれています。 そのプラクティスと設計パターンによって対応できるクラウド開発の課題。 そのプラクティスで重点が置かれている Microsoft Azure Well-Architected F
Web API 設計のベスト プラクティス - Azure Architecture Center
ほとんどの最新の Web アプリケーションでは、クライアントがアプリケーションと対話する際に使用できる API を公開しています。 適切に設計された Web API には、次をサポートする目的があります。 プラットフォームの独立。 API の内部的な実装方法に関係なく、すべてのクライアントが API を呼び出すことができる必要があります。 そのためには、標準プロトコルを使用し、クライアントと Web サービスが交換するデータの形式に同意できるメカニズムを備えている必要があります。 サービスの進化。 Web API はクライアント アプリケーションから独立して進化し、機能を追加できる必要があります。 API の進化に伴い、既存のクライアント アプリケーションが変更なしに引き続き機能する必要があります。 クライアント アプリケーションが機能を十分に使用できるように、すべての機能が検出可能である
APIに利用制限をかけるとしたらどういうやりかたがあるのか - おもしろwebサービス開発日記
この記事はSmartHR Advent Calendar 2020 11日目の記事です。 僕のお手伝いしているSmartHRでは、毎週バックエンドエンジニアが集まり、技術的なトピックについて共有、相談しあうミーティングを開催しています。そのミーティングでは僕がTipsなどを共有するコーナーが常設されています*1。 このエントリでは、そのコーナーで共有した内容をひとつ紹介します。 APIに制限をかける方法について APIを外部に提供するとき、一定の制限をかけてユーザがAPIを乱用するのを防ぐことはよくあることではないでしょうか。素直に考えると「1時間に5000回までAPIを実行できる」のようなやり方を思いつきますね。GitHubのAPIもそのやり方ですし、SmartHRのAPIも同様です。 じゃあそれでいいのでは。となるかもしれませんが少し待ってください。いろんなクライアントがAPIを大量に
面白Web API 100連発 - pastak-pub
エンジニアお茶会 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
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GraphQLはどんな時に使うか