Linux Professional Institute Learning Logo.
main contentにスキップ
  • ホーム
    • 全てのリソース
    • LPI学習教材
    • コントリビューターになる
    • Publishing Partners
    • Publishing Partnerになる
    • About
    • FAQ
    • コントリビューター
    • Roadmap
    • 連絡先
  • LPI.org
031.2 レッスン 1
課題 031: ソフトウェア開発とWebテクノロジー
031.1 ソフトウェア開発の基本
  • 031.1 レッスン 1
031.2 Webアプリケーションのアーキテクチャ
  • 031.2 レッスン 1
031.3 HTTP の基礎
  • 031.3 レッスン 1
課題 032: HTMLドキュメントマークアップ
032.1 HTMLドキュメントの構造
  • 032.1 レッスン 1
032.2 HTMLのセマンティックスとドキュメント階層
  • 032.2 レッスン 1
032.3 HTMLにおける参照と埋め込みリソース
  • 032.3 レッスン 1
032.4 HTMLフォーム
  • 032.4 レッスン 1
課題 033: CSSコンテンツ スタイリング
033.1 CSSの基本
  • 033.1 レッスン 1
033.2 CSSセレクターとスタイルアプリケーション
  • 033.2 レッスン 1
033.3 CSSスタイリング
  • 033.3 レッスン 1
033.4 CSSボックスモデルとレイアウト
  • 033.4 レッスン 1
課題 034: JavaScriptプログラミング
034.1 JavaScriptの実行と構文
  • 034.1 レッスン 1
034.2 JavaScriptデータ構造
  • 034.2 レッスン 1
034.3 JavaScriptの制御構造と関数
  • 034.3 レッスン 1
  • 034.3 レッスン 2
034.4 WebサイトのコンテンツとスタイリングのJavaScript操作
  • 034.4 レッスン 1
課題 035: NodeJSサーバープログラミング
035.1 NodeJSの基本
  • 035.1 レッスン 1
035.2 NodeJS Expressの基本
  • 035.2 レッスン 1
  • 035.2 レッスン 2
035.3 SQLの基本
  • 035.3 レッスン 1
How to get certified
  1. 課題 031: ソフトウェア開発とWebテクノロジー
  2. 031.2 Webアプリケーションのアーキテクチャ
  3. 031.2 レッスン 1

031.2 レッスン 1

Certificate:

Web開発の要点

Version:

1.0

Topic:

031 ソフトウェア開発とWebテクノロジー

Objective:

031.2 Webアプリケーションアーキテクチャ

Lesson:

1 of 1

はじめに

アプリケーション という言葉は、技術用語で広い意味を持っています。アプリケーションがローカルで実行され、その目的が自己充足的である従来のプログラムである場合、アプリケーションの操作インターフェイスとデータ処理コンポーネントの両方が単一の “パッケージ” として統合されます。 Webアプリケーション は、クライアント/サーバモデルを採用し、そのクライアント部分はサーバから取得されて通常はブラウザによってレンダリングされるHTMLに基づいているという点で異なります。

クライアントとサーバ

クライアント/サーバモデルでは、作業の一部はローカルの クライアント側 で行われ、作業の一部はリモートの サーバ側 で行われます。それぞれがどのような作業を行うかは、アプリケーションの目的によって異なりますが、一般的には、ユーザーにインターフェースを提供したり、コンテンツを魅力的にレイアウトするのはクライアント側の役割です。一方、サーバは、アプリケーションのビジネスエンドを実行し、クライアントからのリクエストを処理して応答する役割を担います。例えば、ショッピングアプリケーションでは、クライアントアプリケーションは、ユーザーが商品を選び、支払いを行うためのインターフェースを表示しますが、データソースと取引記録は、ネットワークを介してアクセスされるリモートサーバに保管されます。Webアプリケーションは、通常、HTTP(Hypertext Transfer Protocol)を利用してサーバとの通信を行います。

ブラウザによってロードされると、アプリケーションのクライアント側は、必要または都合のよいときにサーバとの対話を開始します。サーバ側のWebアプリケーションは、利用可能なリクエストとそのリクエスト方法を定義した API(Application Programming Interface) を提供しています。クライアントは、APIで定義された形式でリクエスト要求を作成し、サーバに送信します。サーバは、レスポンス(返答)に必要な条件をチェックし、適切なレスポンスを返します。

モバイルアプリケーションやデスクトップブラウザなどのクライアントは、ユーザーインターフェースやサーバとの通信指示に関しては自己完結型のプログラムですが、ブラウザは、インターフェースやサーバとの通信指示を定義するHTMLページや関連するコンポーネント(画像、CSS、JavaScriptなど)を取得する必要があります。

クライアントとサーバが使用するプログラミング言語やプラットフォームはそれぞれ独立していますが、相互に理解できる通信プロトコルを使用しています。サーバ部分は、ほとんどの場合、グラフィカルなインターフェースを持たないプログラムによって実行され、リクエストにいつでも対応できるように、可用性の高い(障害の発生し辛い)コンピュータ環境で実行されます。一方、クライアント部分は、スマートフォンなど、HTMLインターフェースをレンダリングできるすべてのデバイスで実行されます。

クライアント/サーバモデルの採用は、特定の目的のために不可欠であるだけでなく、各部分を特定の目的のために設計することができるため、アプリケーションの開発と保守のいくつかの側面を最適化することができます。例えば、地図やルートを表示するアプリケーションでは、すべての地図をローカルに保存する必要はありません。ユーザーが興味を持っている場所に関連する地図だけが必要なので、それらの地図だけが中央サーバに要求されます。

開発者はサーバを直接コントロールできるので、サーバが提供するクライアントを変更することもできます。これにより、開発者は、ユーザーが新しいバージョンを明示的にインストールすることなく、アプリケーションを多かれ少なかれ改良することができます。

クライアントサイド

Webアプリケーションは、ブラウザが最新のものであれば、最も人気のあるブラウザのどれでも同じように動作するはずです。一部のブラウザは最近の技術革新と互換性がないかもしれませんが、まだ広く採用されていない機能を使うのは実験的なアプリケーションだけです。

以前は、ブラウザごとに独自の レンダリングエンジン を持っていたり、標準規格の策定や採用における協力関係が希薄だったため、非互換性の問題がより多く発生していました。レンダリングエンジンはブラウザの主要コンポーネントであり、HTMLやその他の関連コンポーネントをインターフェイスの視覚的、インタラクティブな要素に変換する役割を担っています。Internet Explorerをはじめとする一部のブラウザでは、ページの期待される機能を壊さないように、コードに特別な処理が必要でした。

現在では、主要なブラウザ間の違いは最小限に抑えられており、互換性がないということはほとんどありません。実際、ChromeとEdgeは同じレンダリングエンジン(Blinkと呼ばれる)を使用しています。SafariブラウザやiOS App Storeで提供されているブラウザはWebKitエンジンを採用しています。FirefoxはGeckoと呼ばれるエンジンを使用しています。この3つのエンジンで、現在使われているほぼすべてのブラウザが構成されています。3つのエンジンは別々に開発されていますが、オープンソースプロジェクトであり、開発者同士が協力し合うことで、互換性や維持、標準化が図られています。

ブラウザの開発者は互換性を保つために多大な努力をしているので、通常、サーバは単一のタイプのクライアントとはリンクしていません。原則として、HTTPサーバは、HTTPでの通信が可能なあらゆるクライアントと通信することができます。例えば、地図アプリケーションの場合、クライアントはモバイルアプリケーションであったり、サーバからHTMLインターフェイスを読み込むブラウザであったりします。

さまざまなWebクライアント

モバイルやデスクトップのアプリケーションには、インターフェイスがHTMLからレンダリングされ、ブラウザと同様にプログラミング言語としてJavaScriptを使用できるものがあります。しかし、ブラウザに読み込まれたクライアントとは異なり、ネイティブクライアントが機能するために必要なHTMLと必要なコンポーネントは、アプリケーションのインストール時からローカルに存在しています。実際、このように動作するアプリケーションは、HTMLページとほとんど同じです(両者は同じエンジンでレンダリングされる可能性さえあります)。また、 プログレッシブWebアプリ(PWA:Progressive Web Apps) と呼ばれる、サーバとの即時通信を必要としない機能に限定して、オフライン用にWebアプリケーションのクライアントをパッケージ化する仕組みもあります。アプリケーションの機能については、ブラウザで実行してもPWAでパッケージ化しても違いはありませんが、後者の方がローカルに保存される内容を開発者がよりコントロールできるという点が異なります。

HTMLからインターフェースをレンダリングすることは、非常に繰り返し行われるアクティビティであるため、エンジンは通常、オペレーティングシステムに含まれる独立したソフトウェアコンポーネントとなっています。別のコンポーネントとして存在することで、アプリケーションパッケージに組み込むことなく、さまざまなアプリケーションに組み込むことができます。また、このモデルでは、レンダリングエンジンのメンテナンスをOSに委ねることで、アップデートを容易にしています。このような重要なコンポーネントを最新の状態に保つことは、起こりうる障害を回避するために非常に重要です。

配信方法に関わらず、HTMLで記述されたアプリケーションは、エンジンが作成した抽象化レイヤー上で実行され、分離された実行環境として機能します。特に、ブラウザ上で動作するクライアントの場合、アプリケーションが自由に使えるのは、ブラウザが提供するリソースだけです。ページの要素を操作したり、HTTPでファイルを要求したりといった基本的な機能は常に利用できます。ローカルファイル、地理的な位置、カメラ、マイクへのアクセスなど、機密情報を含む可能性のあるリソースは、アプリケーションが使用する前に、ユーザーの明示的な承認が必要です。

Webクライアントの言語

サーバ上で動作するクライアント側のWebアプリケーションの中心となるのがHTMLドキュメントです。HTMLドキュメントは、ブラウザが表示するインターフェース要素を構造化して表示するだけでなく、クライアントの正しい表示と操作に必要なすべてのファイルのアドレスを含んでいます。

HTMLだけでは、より精巧なインターフェースを構築するための汎用性が低く、また、汎用的なプログラミング機能も持っていません。このため、クライアントアプリケーションとして機能すべきHTMLドキュメントには、必ず1セット以上のCSSとJavaScriptが付属されています。

CSSは、別のファイルとして提供される場合と、HTMLファイル自体に直接含まれる場合があります。CSSの主な目的は、HTMLインターフェースの要素の外観やレイアウトを調整することです。厳密には必要ではありませんが、より洗練されたインターフェイスでは、通常、ニーズに応じて要素のCSSプロパティを変更する必要があります。

JavaScriptは実質的に不可欠なコンポーネントです。JavaScriptで書かれたプロシージャは、ブラウザ上のイベントに応答します。これらのイベントは、ユーザーによって引き起こされるものもあれば、非インタラクティブなものもあります。JavaScriptがなければ、HTMLドキュメントは実質的にテキストと画像に限られてしまいます。HTMLドキュメントでJavaScriptを使用すると、ハイパーリンクやフォーム以外にもインタラクティブ性を拡張することができ、ブラウザが表示するページを従来のアプリケーション・インターフェースのようにすることができます。

JavaScriptは汎用的なプログラミング言語ですが、主にWebアプリケーションで使用されます。ブラウザの実行環境の機能は、JavaScriptのキーワードでアクセスでき、目的の操作を行うためのスクリプトで使用されます。例えば、 document という用語は、JavaScriptのコードの中で、そのJavaScriptのコードに関連するHTMLドキュメントを指すために使われます。JavaScript言語の文脈では、 document は、HTMLドキュメント上の任意の要素から情報を取得するために使用できるプロパティやメソッドを持つ グローバルオブジェクト です。さらに重要なことは、 document オブジェクトを使ってその要素を変更し、JavaScriptで書かれたカスタムアクションに関連付けることができるということです。

Web技術をベースにしたクライアントアプリケーションは、互換性のあるWebブラウザがあればどんなデバイスでも動作するため、マルチプラットフォームに対応しています。

しかし、ブラウザに限定されることで、ネイティブアプリケーションに比べてWebアプリケーションには制限があります。ブラウザが仲介することで、より高度なプログラミングが可能になり、セキュリティも向上しますが、その反面、処理能力やメモリ消費量が増大します。

開発者は、ブラウザにさらなる機能を提供したり、JavaScriptアプリケーションのパフォーマンスを向上させるために絶えず努力していますが、JavaScriptなどのスクリプトの実行には、同じハードウェアのネイティブプログラムと比較して不利になるという本質的な側面があります。

ブラウザ上で動作するJavaScriptアプリケーションのパフォーマンスを大幅に向上させる機能として、 Webアッセンブリー があります。Webアッセンブリーは、C言語のような、より効率的な低レベル言語で書かれたソースコードを生成するコンパイル済みのJavaScriptの一種です。WebAssemblyは、従来のJavaScriptで書かれたプログラムを実行する際にブラウザが行う変換の多くを避けることができるため、主にプロセッサ負荷の高いアクティビティを高速化することができます。

アプリケーションの実装内容にかかわらず、すべてのHTMLコード、CSS、JavaScript、マルチメディアファイルは、まずサーバから取得する必要があります。ブラウザはこれらのファイルをインターネットのページと同じように、つまり、ブラウザがアクセスするアドレスで取得します。

WebアプリケーションのインターフェイスとなるWebページは、通常のHTMLドキュメントと同様に、付加的な動作を行います。従来のページでは、ユーザーはリンクをクリックすると別のページに移動します。Webアプリケーションは、ブラウザのウィンドウに新しいページをロードすることなく、ユーザーのイベントに応答することができます。このようなHTMLページの標準的な動作の変更は、JavaScriptのプログラミングによって行われます。

例えば、Webメールクライアントは、ページを離れることなくメッセージを表示したり、メッセージフォルダを切り替えたりすることができます。これを可能にしているのは、クライアントがJavaScriptを使ってユーザーのアクションに反応し、サーバに適切なリクエストをするためです。ユーザーが受信箱内のメッセージの件名をクリックすると、このイベントに関連付けられたJavaScriptコードが、そのメッセージの内容をサーバにリクエストします(対応するAPI呼び出しを使用)。クライアントが応答を受け取るとすぐに、ブラウザは同じページの適切な部分にメッセージを表示します。Webメールクライアントによって戦略は異なるかもしれませんが、どのクライアントもこの原理は同じです。

したがって、サーバは、クライアントを構成するファイルをブラウザに提供するだけでなく、Webメールクライアントが特定のメッセージの内容を要求するときのようなリクエストを処理できなければなりません。クライアントが行うすべてのリクエストには、サーバが応答するための手順があらかじめ定義されています。サーバのAPIでは、リクエストがどの手順を参照しているかを識別するためのさまざまなメソッドを定義できます。最も一般的な方法は次のとおりです。

  • ユニフォーム・リソース・ロケーター(URL)を介したアドレス

  • HTTPヘッダーのフィールド

  • GET/POST メソッド

  • WebSockets(WebSocket API)

リクエストの目的や、開発者が考慮するその他の基準によっては、ある方法が他の方法よりも適している場合があります。一般的に、Webアプリケーションでは、それぞれの状況に応じて、複数の方法を組み合わせて使用します。

Representational State Transfer (REST)パラダイムは、HTTPの基本的なメソッドをベースにしているため、Webアプリケーションの通信に広く利用されています。HTTPリクエストのヘッダーは、実行すべき基本的な操作を定義するキーワードで始まります。 GET 、 POST 、 PUT 、 DELETE などの基本的な操作を定義するキーワードで始まり、その操作が適用される対応するURLが示されます。アプリケーションがより具体的な操作を必要とし、要求された操作についてより詳細な説明を必要とする場合は、GraphQLプロトコルがより適切な選択肢となるでしょう。

クライアント/サーバモデルを使用して開発されたアプリケーションは、通信が不安定になることがあります。このため、クライアントアプリケーションは、常に効率的なデータ転送戦略を採用し、一貫性を保ちつつ、ユーザーエクスペリエンス(UX)を損なわないようにする必要があります。

サーバサイド

Webアプリケーションの主役であるにもかかわらず、サーバは通信の受動側であり、クライアントからのリクエストに応答するだけです。Webの専門用語では、 サーバ は、リクエストを受信するマシン、HTTPリクエストを特別に処理するプログラム、またはリクエストに対するレスポンスを生成する受信者スクリプトを指します。後者の定義は、Webアプリケーションアーキテクチャの文脈では最も適切なものですが、これらはすべて密接に関連しています。アプリケーションサーバの開発者にとって、これらは部分的にしか関係ありませんが、マシン、オペレーティングシステム、HTTPサーバは、アプリケーションサーバを実行する上で基本的な要素であり、交差することが多いため、無視できません。

リクエストからのパスの処理

ApacheやNGINXなどのHTTPサーバは、通常、アプリケーションのニーズを満たすために特定の設定変更を必要とします。従来のHTTPサーバは、デフォルトでは、リクエストで示されたパスを、ローカルファイルシステム上のファイルに直接関連付けます。例えば、WebサイトのHTTPサーバがHTMLファイルを /srv/www ディレクトリに置いている場合、パス /en/about.html を指定したリクエストは、ファイル /srv/www/en/about.html が存在すれば、その内容をレスポンスとして受け取ります。より洗練されたWebサイト、特にWebアプリケーションでは、さまざまなタイプのリクエストに対してカスタマイズされた処理が求められます。このシナリオでは、アプリケーションの実装の一部として、アプリケーションの要件を満たすためにHTTPサーバの設定を変更します。

あるいは、HTTPリクエストの管理とアプリケーションコードの実装を一元化し、開発者がプラットフォームの詳細よりもアプリケーションの目的に集中できるようにしたフレームワークもあります。例えば、Node.jsのためのExpressフレームワークは、リクエストのマッピングとそれに対応するプログラミングをすべてJavaScriptで実装しています。通常、クライアントのプログラミングはJavaScriptで行われるため、コードメンテナンスの観点から、クライアントとサーバで同じ言語を使用することを良しとする開発者は多いです。その他、フレームワークや従来のHTTPサーバでサーバ側の実装によく使われる言語としては、PHP、Python、Ruby、Java、C#などがあります。

データベース管理システム

クライアントが受信または要求したデータをサーバにどのように保存するかは、開発チームの判断に委ねられていますが、ほとんどの場合に適用される一般的なガイドラインがあります。静的コンテンツ(画像、JavaScript、CSSなどの短期的に変化しないコード)は、従来のファイルとして、サーバのファイルシステムに保存するか、 コンテンツ配信ネットワーク (CDN:content delivery network)に分散して保存するのが便利です。一方、Webメールアプリケーションの電子メールメッセージ、ショッピングアプリケーションの商品情報、トランザクションログなど、その他のコンテンツは、 データベース管理システム (DBMS)に保存するのが便利です。

最も伝統的なタイプのデータベース管理システムは、 リレーショナルデータベース です。このデータベースでは、アプリケーションの設計者がデータテーブルと、各テーブルが受け入れる入力フォーマットを定義します。データベース内の一連のテーブルには、アプリケーションが消費・生成するすべての動的データが含まれます。例えば、ショッピングアプリでは、ストア内の各商品の詳細を記載したエントリを含むテーブルと、ユーザーが購入したアイテムを記録するテーブルを持つことができます。購入した商品のテーブルには、商品テーブルのエントリへの参照が含まれており、テーブル間のリレーションが作成されています。この方法は、データの保存とアクセスを最適化するだけでなく、データベース管理システムで採用されている言語を使用して、結合されたテーブルへの問い合わせを可能にします。最も一般的なリレーショナルデータベース言語は、SQLite、MySQL、MariaDB、PostgreSQLなどのオープンソースデータベースで採用されている SQL(Structured Query Language: "エスキューエル" または "sequel" と発音) です。

リレーショナルデータベースに代わるものとして、データに厳密な構造を必要としないデータベースの形態があります。これらのデータベースは、 non-relational databases または単に NoSQL と呼ばれています。リレーショナルデータベースと同じような機能を備えている場合もありますが、データの保存やアクセスをより柔軟に行えるようにすることに重点が置かれており、データを処理するタスクはアプリケーション自身に委ねられています。MongoDB、CouchDB、Redisなどが一般的な非リレーショナルデータベース管理システムです。

コンテンツのメンテナンス

どのようなデータベースモデルを採用するかにかかわらず、アプリケーションはデータを追加しなければならず、おそらくアプリケーションの寿命が尽きるまでデータを更新しなければなりません。Webメールなどの一部のアプリケーションでは、クライアントを使ってメッセージを送受信する際に、ユーザー自身がデータベースにデータを提供します。または、ショッピングアプリケーションのように、アプリケーションのメンテナが、プログラミングに頼らずにデータベースを変更できるようにすることが重要な場合もあります。そのため、多くの組織では、技術者ではないユーザーでもアプリケーションを管理できるように、ある種の コンテンツ管理システム(CMS:content management system) を採用しています。したがって、ほとんどのWebアプリケーションでは、少なくとも2種類のクライアントを実装する必要があります。一般ユーザーが使用する非特権クライアントと、アプリケーションが提示する情報を維持・更新するために特別なユーザーが使用する特権クライアントです。

演習

  1. Webアプリケーションのクライアントを作成するために、HTMLと一緒に使用されるプログラミング言語は何ですか?

  2. Webアプリケーションの検索は、ネイティブアプリケーションの検索とどう違うのでしょうか?

  3. ローカルハードウェアへのアクセスにおいて、Webアプリケーションとネイティブアプリケーションの違いは何ですか?

  4. クライアント側のWebアプリケーションの特徴として、通常のWebページとの違いを1つ挙げてください。

発展演習

  1. CPUを多用するWebアプリケーションのクライアントのパフォーマンス低下を解消するために、最新のブラウザが提供する機能とは何でしょうか?

  2. Webアプリケーションでクライアント/サーバ間の通信にRESTパラダイムを使用している場合、クライアントがサーバに特定のリソースの消去を要求するときに使用すべきHTTPメソッドはどれでしょうか。

  3. Apache HTTPサーバがサポートする5つのサーバスクリプティング言語を挙げてください。

  4. なぜ非リレーショナルデータベースはリレーショナルデータベースよりもメンテナンスやアップグレードが容易だと考えられていますでしょうか?

まとめ

このレッスンでは、Web開発の技術とアーキテクチャにおけるコンセプトと標準について説明します。原理は単純で、Webブラウザがクライアントアプリケーションを実行し、そのクライアントアプリケーションがサーバで実行されているコアアプリケーションと通信するというものです。原理的には単純ですが、Webアプリケーションは、Web上のクライアントとサーバのコンピューティングの原理を採用するために、多くの技術を組み合わせる必要があります。このレッスンでは、次のような概念を説明しました。

  • WebブラウザとWebサーバの役割

  • 一般的なWeb開発技術と標準

  • Webクライアントがサーバと通信する方法

  • Webサーバとサーバデータベースの種類

演習の回答

  1. Webアプリケーションのクライアントを作成するために、HTMLと一緒に使用されるプログラミング言語は何ですか?

    JavaScript

  2. Webアプリケーションの検索は、ネイティブアプリケーションの検索とどう違うのでしょうか?

    Webアプリケーションはインストールされません。その代わり、アプリケーションの一部はサーバ上で実行され、クライアントインターフェースは通常のWebブラウザで実行されます。

  3. ローカルハードウェアへのアクセスにおいて、Webアプリケーションとネイティブアプリケーションの違いは何ですか?

    ストレージ、カメラ、マイクなどのローカルリソースへのアクセスはすべてブラウザが仲介し、動作にはユーザーの明示的な承認が必要です。

  4. クライアント側のWebアプリケーションの特徴として、通常のWebページとの違いを1つ挙げてください。

    従来のWebページとのインタラクションは、基本的にハイパーリンクとフォームの送信に限定されていますが、Webアプリケーションのクライアントは、従来のアプリケーション・インターフェースに近いものです。

発展演習の回答

  1. CPUを多用するWebアプリケーションのクライアントのパフォーマンス低下を解消するために、最新のブラウザが提供する機能とは何でしょうか?

    開発者は、クライアントアプリケーションのCPU負荷の高い部分をWebAssemblyで実装することができます。WebAssemblyのコードは、命令の変換が少なくて済むため、一般的に従来のJavaScriptよりもパフォーマンスが高くなります。

  2. Webアプリケーションでクライアント/サーバ間の通信にRESTパラダイムを使用している場合、クライアントがサーバに特定のリソースの消去を要求するときに使用すべきHTTPメソッドはどれでしょうか。

    RESTは標準的なHTTPメソッドに依存しているので、この場合は標準的な DELETE メソッドを使用する必要があります。

  3. Apache HTTPサーバがサポートする5つのサーバスクリプティング言語を挙げてください。

    PHP、Go、Perl、Python、およびRubyです。

  4. なぜ非リレーショナルデータベースはリレーショナルデータベースよりもメンテナンスやアップグレードが容易だと考えられていますでしょうか?

    非リレーショナルデータベースは、リレーショナルデータベースとは異なり、データをあらかじめ定義された構造に合わせる必要がないため、既存のデータに影響を与えることなく、データ構造の変更を容易に行うことができます。

Linux Professional Insitute Inc. All rights reserved. 学習資料をご覧ください: https://learning.lpi.org
ここでの作成物は、Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International Licenseの下でライセンスされています。

次のレッスン

031.3 HTTP の基礎 (031.3 レッスン 1)

次のレッスンを読む

Linux Professional Insitute Inc. All rights reserved. 学習資料をご覧ください: https://learning.lpi.org
ここでの作成物は、Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International Licenseの下でライセンスされています。

LPIは非営利団体です。

© 2023 Linux Professional Institute(LPI)は、オープンソースプロフェッショナル向けのグローバルな認定基準およびキャリアサポート組織です。200,000人以上の認定保持者を擁する、世界初かつ最大のベンダー中立Linuxおよびオープンソース認定機関です。LPIは180か国以上で認定プロフェッショナルを擁し、複数の言語で試験を実施し、何百ものトレーニングパートナーを擁しています。

私たちの目的は、オープンソースの知識とスキルの認定資格を世界中からアクセスできるようにすることで、誰にとっても経済的で創造的な機会を可能にすることです。

  • LinkedIn
  • flogo-RGB-HEX-Blk-58 Facebook
  • Twitter
  • お問い合わせ
  • 個人情報とCookieポリシー

間違いを見つけたり、このページを改善したいですか? 私たちに知らせてください。.

© 1999–2023 The Linux Professional Institute Inc. All rights reserved.