InfoQ ホームページ API に関するすべてのコンテンツ
-
APIゲートウェイの過去、現在、そして未来
エッジは単純なハードウェアロードバランサとして始まり、APIゲートウェイやコンテンツ配信ネットワーク、ロードバランサを構成する、ハードウェアとソフトウェアプロキシのフルスタックへと進化しました。今回の記事では、アプリケーションアーキテクチャとワークフローの進化をもとに、データセンタエッジの進化の軌跡を追ってみたいと思います。
-
ソフトウェアアーキテクチャと設計 - InfoQトレンドレポート、2020年4月
InfoQのエディタたちが、2020年のソフトウェアのアーキテクチャと設計の分野におけるトピックをどう見たのか、基本的なアーキテクチャパターン、フレームワークの利用、設計スキルを中心に、その概要をお伝えします。
-
API Gatewayとサービスメッシュがアプリケーション最新化へのドアを開く
アプリケーションの動作する下位インフラストラクチャからアプリケーションを切り離す”最新化”には、イノベーションの実現、コスト削減、セキュリティ向上などのメリットがあります。API Gatewayはアプリケーションの外部ユーザからの分離を、サービスメッシュは内部ユーザ相互の切り離しを、それぞれ可能にします。
-
API GatewayサービスをClojureからGo言語に書き直す - AppsFlyerによる実例報告
AppsFlyerはマイクロサービスアーキテクチャ方式で構築されており，１日700億近いHTTPリクエストを処理しています。すべてのフロントエンドサービスをラップしてシステムへのエントリポイントとなるのは，API Gatewayと呼ばれるミッションクリティカルな(非マイクロ)サービスです。この記事では，Clojureベースのゲートウェイから，新たに設計されたGoベースの実装に移行した経験を報告します。
-
RESTlessnessに打ち勝つ
GraphQLやgRPC，Apache Kafkaといった新しいAPIプロトコルが，RESTに基づいたHTTP APIに代わるものとして人気を集めています。RESTの代わりを探すのではなく，ソフトウェアエンジニア産業は，成熟したRESTエコシステムを基盤として，新たなプロトコルの技術的長所を探求する手段を模索するべきです。
-
RSocketでRESTに安息(Rest)を
REST(Representational State Transfer)は、マイクロサービス間の通信におけるデファクトスタンダードになっています。これは望ましいことではない、と著者は主張します。現代的なサービスを開発するには、現代的な素材でHTTPを置き換える必要があります。オープンソースのRSocketはサービスのために設計されました。アプリケーションレベルのフロー制御を組み込んだ、コネクション指向でメッセージ駆動のプロトコルです。
-
リアクティブAPIの設計，実装，利用
リアクティブプログラミングはJavaのホットな話題です。非ブロックAPIを使いたいにせよ，マイクロサービスの増加に伴って増加するレイテンシに対処したいにせよ，あるいは単に計算リソースを効率的に使用したいにせよ，今こそ有望なプログラミングモデルとしてのリアクティブに注目すべき時です。今回の記事では，リアクティブAPIの設計，実装，利用に用いるべき選択肢をいくつか紹介します。
-
Yogaを使ってRESTを柔軟にする
クライアントのニーズに従ってRESTの応答をより細かく制御したい場合、オープンソースのYogaは既存のRESTアプリケーションと統合する機能を提供します。Yogaはセレクタ機能を提供し、射影や選択、結合のような機能をクライアントに提供します。
-
紹介：Restful Objects
Restful Objectsは、ドメイン·オブジェクト·モデルのハイパーメディアAPIの公開仕様である。仕様のバージョン 1.0.0は、リリースされたばかりで、すでに仕様を実装した2つのオープンソースフレームワークがあり、1つはJavaプラットフォーム用で、もう1つが.NET用である。
-
SOAP から REST へ - その方法と意義
REST API の数はここ５年間で急激に増加しています。しかしそこには実装上の矛盾が数多く存在し，多数の開発者がその原因である RESTful アーキテクチャ定義に合意点を見出すための努力を続けています。この記事では iPaaS (Integration Platform as a Service) である Mule iON が，公開 API と API マッシュアップに一貫性を実現している方法について説明します。
-
-
信頼できるメッセージングは、不要。
Marc de Graauw氏は、WS-ReliableMessagingのようなトランスポート レベルの信頼性メカニズムが必要だ、という考えに対して、挑戦している。そのために、オランダのヘルスケアのSOAを例に、いかに、順番処理と正確に１度の処理を実現するビジネス論理の方が、ずっとうまくジョブを処理できるかを説明している。