ブラウザからTCP, UDPソケットを操作するDirect Sockets API - ASnoKaze blog
2020/01/14: 実際に動くのを確認しました asnokaze.hatenablog.com (2020/09/17 注釈: Raw SocketsからDirect Socketsに名称が変更されました) ブラウザでTCP, DUPソケットを操作可能にする「Direct Sockets API」という仕様がW3CのWICGで議論されている。 また、blink-devでも「Intent to Prototype: Raw Sockets API」とプロトタイプの議論が行われている。 多くの方がセキュリティ上の懸念を抱くと思うが、ドキュメントでも慎重に検討すると書かれている。GithubでIssueを立てることも可能なので、思うことがある方は、まだまだ議論は始まったばかりでもあるので是非フィードバックされると良いと思う。(割と普通に聞いてもらえます) なお、Raw Socketsという名
Design APIs: The Evolution of Design Systems
Design systems enable designers and developers to quickly create quality software on a massive scale. As the needs of software-driven businesses grow even larger, design systems are evolving — they are beginning to look and work like APIs. In software development, “API” stands for “Application Programming Interface.” An API is a reliable way for two or more programs to cooperate. It allows program
HTTP API の設計方向
見てみると、たしかに Get 系の API だとしても POST を利用しているし、API の URL 設計に get_shared_link_file のようによく言われる REST っぽい設計は使っていなかった。 この方針は同意だ。自分は結構前に REST っぽい API を捨てることにした。だからといって REST API がダメだとかは思っていない。 一般ユーザが使う場合の API は REST API であるほうが慣れ親しんでいる場合が多いからだ。 AWS で利用されている HTTP API 仕様AWS の DynamoDB の Erlang/OTP ドライバーを書いているときに気づいたのだが、AWS の一部のサービスはかなり独特な API の仕様になっている。
API仕様を書く（まとめ）: 柴田 芳樹 (Yoshiki Shibata)
「API仕様を書く」として私自身の過去の経験を書いたものを読みやすく並べてみました。 API仕様を書く（1） API仕様を書く（2） API仕様を書く（3） API仕様を書く（4） API仕様を書く（5）ー gRPC protoファイル ー API仕様を書く（6）ー gRPC protoファイル（2） ー API仕様を書く（7） ちょうど同じような内容が『A Philosophy of Software Design』に書かれていました。 関連する章は、第12章「Why Write Comments? The Four Execuses」と第15章「Write The Comments First」です。第12章では、コメントを書かない理由として多くのソフトウェアエンジニアが挙げる理由について反証しています。第15章ではコメントを最初に書くことの有用性を説いています。ここでのコメントは、私
Stripe Sources APIにおける決済の抽象化 - kymmt
この記事はGMOペパボ Advent Calendar 2018の23日目の記事です。 GMOペパボのAdvent Calendarと言っておきながら、Stripeが提供しているWeb APIの話をします。 Stripeの決済用Web APIでは、sourceという概念を通じて多様な決済方法を抽象化して表現しています。このsourceの概念がEC系Webサービス*1を開発している人間としては興味深いものだったので紹介します。 sourceとは Stripe公式のリソースは次のあたりのものです。 stripe.com stripe.com sourceは多様な決済方法を取り扱うために導入されている概念です。sourceの状態がchargeable（課金可能）になると、買い手に対してcharge（課金）することができます。 もう少し詳しく説明すると、sourceは買い手が決済するために使う「モ
RailsのAPI開発にスキーマ駆動開発を導入して、品質と開発スピードを高める - freee Developers Blog
こんにちは、freee API開発チームのkotegawaです。 この記事はfreee Developers Advent Calender 2018の19日目の記事です。 freeeのAPI開発 freeeでは今年の7月から、API開発専任チームが新設されました。 API開発チームでは、 社外向け新規APIの開発 API開発基盤の強化 新規プロダクトの開発 などの業務を社内の認証基盤チームやインフラチームと協力しながら行っています。 今日はAPIチーム発足前にfreeeが抱えていたAPIの課題と、それを解決するために導入したスキーマ駆動開発について紹介します。 APIチーム誕生前の課題 もともと弊社のAPIの課題として、以下のようなものがありました。 APIドキュメントと実際の実装に差異があった 開発する度にAPIドキュメントを更新することにメンテナンスコストがかかっており、また手動で更
シンプルさとパフォーマンスを両立した API 設計と実装の一例 - HeartRails Tech Blog
こんにちは、エンジニアの村田です。今回はシンプルさとパフォーマンスを両立した API を作るためにはどうすればよいのかについて述べていきます。 背景 いままで API サーバーを作ってきて、シンプルな API にすればパフォーマンスが犠牲に、パフォーマンスを優先すれば実装が複雑になって保守が大変になるということを経験してきました。具体的には、 関連リソースの Entity が何重にもネストしていたり、同じリソースに一覧用、詳細用などの Entity があり実装、保守が大変 1. の問題を解消するためにシンプルな API にする 2. では N+1 の問題がありパフォーマンスが悪い 1. 2. の問題を解消するためにリソースの Entity はシンプルにしつつ、パラメーターで関連リソースを指定すると関連リソースの Entity を埋め込んで返すようにする 4. だと関連リソースの権限管理やペ
BFF（Backends For Frontends）実践における3つのアンチパターンと、その回避策
BFF（Backends For Frontends）実践における3つのアンチパターンと、その回避策：マイクロサービス/API時代のフロントエンド開発（終） マイクロサービス/API時代のフロントエンド開発に求められる技術の一つ、Backends For Frontends（BFF）について解説する連載。最終回は筆者の経験に基づいて、3つのBFFアンチパターンと、その回避策を紹介します。 実案件にBFFを複数回導入した筆者の経験に基づいて原因と回避策を解説 マイクロサービス/API時代のフロントエンド開発に求められる技術の一つ、Backends For Frontends（BFF）について解説する本連載「マイクロサービス/API時代のフロントエンド開発」。前回はBFFに関する5つのユースケースを紹介しました。 BFFはアーキテクチャのパターンの一種ですが、どんなときでも当てはまるものではあ
GitHub - stripe/stripe-mock: stripe-mock is a mock HTTP server that responds like the real Stripe API. It can be used instead of Stripe's testmode to make test suites integrating with Stripe faster and less brittle.
stripe-mock is a mock HTTP server based on the real Stripe API. It accepts the same requests and parameters that the Stripe API accepts, and rejects requests whose parameters are not recognized or have incorrect types. Its responses resemble the responses of the real Stripe API in terms of data type; however, stripe-mock does not attempt to reproduce the behavior of the real Stripe API at all. It
RESTful API のおさらい - onk.ninja
RESTful API のおさらい 前後リンク RESTful API のおさらい Rails での JSON API 実装まとめ スキーマファースト開発 The NEXT of REST REST の歴史 REST (REpresentational State Transfer) という言葉は 2000 年に Roy Fielding の博士論文で初出しました。 (思想としてはその前からあった？ REST 入門) 日本では 2005 年ぐらいから徐々に流行りだして、 2006 年に WEB+DB Press で特集や連載が組まれる等が行われ、 (Rails 2.x が RESTful を打ち出した) 2007 年の終わりには web 開発者の間では一般化した言葉になっていたって印象。 なぜ REST が必要になったのか はるか昔はメインフレーム上で全部入りのアプリケーションを開発してい
API 設計ガイド | Cloud API Design Guide | Google Cloud
フィードバックを送信 API 設計ガイド コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。 変更履歴 はじめに これは、ネットワーク API の一般的な設計ガイドです。2014 年以来 Google 内部で使用され、Cloud API やその他の Google API を設計するときに Google が従うガイドです。この設計ガイドは、外部のデベロッパーへの情報提供と、互いの連携作業の効率化のためにここで共有されています。 Cloud Endpoints のデベロッパーには、このガイドは、gRPC API を設計するときに特に役立つことがあり、そのような場合にはこれらの設計原則を使用することを強くおすすめします。ただし、このガイドの使用は必須ではありません。Cloud Endpoints と gRPC はガイドに従わなくても使用できます。 このガイドは、gR
Bonfire API #1 ～ヤフー、メルカリ、Gunosy、LINEの課題と解決策～
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは! Bonfire API運営の出水です。 2月1日(木)に弊社のコワーキングスペースLODGEでBonfire API #1を開催しました! Bonfire APIとは、APIやサーバーサイド技術にフォーカスした情報共有を定期的に行う勉強会/交流会イベントです。 目まぐるしく進化を続ける技術や市場環境との向き合い方について共有することで、新しい知見を得たり技術交流の輪を広げたりすることのできる場を目指しています。 テーマ「APIの役割の多様化」 Bonfire API第1回のテーマは「APIの役割の多様化」です。 海外進出によるリージョンの多様化や開発者向けAPIの公開に伴う利用者の多様化などの課題にどう対応しているか
GraphQL vs REST: Caching
Recently I wrote GraphQL vs REST: Overview, giving a hype-free outline of the differences between REST and GraphQL. One section that would not have fit into that already lengthy article was caching, so I thought I'd fire that out next. Comparing how caching is used for the two approaches is tricky, because despite common opinion, REST has nothing to do with HTTP. REST is usually implemented in HTT
Swagger、GraphQL、gRPC+Protocol Buffersの概観 - Qiita
この記事について この記事は、DroidKaigi2018の以下の発表に刺激を受けて書いた記事です。 まだAPI定義管理で消耗してるの？〜Swaggerを用いた大規模アプリ時代のAPI定義管理とコードジェネレート〜 すばらしきGraphQLのSEKAIへようこそ gRPCとProtocol Buffersで一味違うAndroid通信 上記の発表では、Swagger、GraphQL、gRPCとProtocol Buffersという言葉が出てきました。これらはサーバー/クライアント間のAPI通信を実現するために役立つものです。しかし、Swaggerはツール、GraphQLはクエリ言語、gRPCとProtocol Buffersは設計指針（を実装したライブラリ）とデータフォーマットというように同格に扱えるものではないので、ちょっと混乱してしまいます。 そこで、この記事ではサーバー/クライアント間
Announcing Prisma 2: Confidence and productivity for your database
Accessing databases in Node.js and TypeScript can feel brittle and painful. Prisma removes the pain with an auto-generated and type-safe query builder that's tailored to your data! Try it out! Contents The problem: Working with databases is difficult The solution: Prisma makes databases easy What you can build with Prisma A strong ecosystem growing around Prisma Getting started with Prisma A huge
物理サーバを選定する際のポイント – Eureka Engineering – Medium
Eureka EngineeringLearn about Eureka’s engineering efforts, product developments and more.
Gyazo の Web API の設計変更 - r7kamura - Medium
業務委託として現在 Nota 社の Gyazo のサーバサイドの開発をお手伝いさせてもらっているのですが、その中でやっていることについて幾つか紹介したいと思い、今回は開発環境で全面的に Docker を使うようにしたという話について書こ… ここでは、Web ブラウザやその他のクライアントから HTTP を介して利用し、JSON などのデータフォーマットでクライアントアプリケーションとやり取りを行うようなエンドポイントのことを Web API と呼んでいます。 Jbuilder からの移行これまでのコードでは、JSON を生成するために Jbuilder というライブラリを使っていました。これは DSL を用いて JSON を生成するライブラリで、Rails の場合は ActionView と協調して動きます。 Jbuilder からの変更の理由は幾つかあるのですが、主要な理由を挙げると、以
REST is the new SOAP
Written by Pascal Chambon, reviewed by Raphaël Gomès Update: this article mostly deals with the RESTish ecosystem, which now constitutes a major part of webservices. For more in-depth analysis of the original REST, and of HATEOAS, see my follow-up article. How come REST means so much WORK? This is both a paradox, and a shameless pun. Let’s dive further into the artificial problems born from this d
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Building real-time Analytics APIs at scale
GraphQL対REST - 考慮すべき点
