BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ API に関するすべてのコンテンツ

  • ソフトウェアアーキテクチャと設計 - InfoQトレンドレポート、2020年4月

    InfoQのエディタたちが、2020年のソフトウェアのアーキテクチャと設計の分野におけるトピックをどう見たのか、基本的なアーキテクチャパターン、フレームワークの利用、設計スキルを中心に、その概要をお伝えします。

  • API Gatewayとサービスメッシュがアプリケーション最新化へのドアを開く

    アプリケーションの動作する下位インフラストラクチャからアプリケーションを切り離す”最新化”には、イノベーションの実現、コスト削減、セキュリティ向上などのメリットがあります。API Gatewayはアプリケーションの外部ユーザからの分離を、サービスメッシュは内部ユーザ相互の切り離しを、それぞれ可能にします。

  • API GatewayサービスをClojureからGo言語に書き直す - AppsFlyerによる実例報告

    AppsFlyerはマイクロサービスアーキテクチャ方式で構築されており,1日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 の数はここ5年間で急激に増加しています。しかしそこには実装上の矛盾が数多く存在し,多数の開発者がその原因である RESTful アーキテクチャ定義に合意点を見出すための努力を続けています。この記事では iPaaS (Integration Platform as a Service) である Mule iON が,公開 API と API マッシュアップに一貫性を実現している方法について説明します。

  • SOAの未来はRESTか

    この記事ではBoris Lublinsky氏がSOAとRESTのアーキテクチャ上の違いを説明し、SOAの実装としてのRESTを使う方法を説明します。

  • 信頼できるメッセージングは、不要。

    Marc de Graauw氏は、WS-ReliableMessagingのようなトランスポート レベルの信頼性メカニズムが必要だ、という考えに対して、挑戦している。そのために、オランダのヘルスケアのSOAを例に、いかに、順番処理と正確に1度の処理を実現するビジネス論理の方が、ずっとうまくジョブを処理できるかを説明している。

  • 実践RESTful HTTP

    Gregor Roth氏から、RESTful HTTPの基礎に関してオーバービューを提供し、RESTful HTTPアプリケーションを設計する上で開発者が直面する典型的な問題に関して取り上げる。その中で、RESTアーキテクチャスタイルをいかに実践していくかを示す。Gregor氏は、URIの命名の共通して利用されるアプローチや、統一インターフェースをつかったリソースへのインタラクション、PUTとPOSTの使い分け、CRUD以外の操作のサポートなどについてとりあげている。

BT