質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

新規登録して質問してみよう
ただいま回答率
85.35%
Webサーバー

Webサーバーとは、HTTPリクエストに応じて、クライアントに情報を提供するシステムです。

API

APIはApplication Programming Interfaceの略です。APIはプログラムにリクエストされるサービスがどのように動作するかを、デベロッパーが定めたものです。

Q&A

2回答

5269閲覧

APIサーバーとは?マイクロサービスとの関連性は?

kazu25

総合スコア27

Webサーバー

Webサーバーとは、HTTPリクエストに応じて、クライアントに情報を提供するシステムです。

API

APIはApplication Programming Interfaceの略です。APIはプログラムにリクエストされるサービスがどのように動作するかを、デベロッパーが定めたものです。

0グッド

2クリップ

投稿2020/09/28 04:20

編集2020/09/28 04:42

最近、フロント側でJSのフレームワーク(Vueやreact)を用いてシングルページアプリケーションを作り、サーバーサイド側は簡易フレームワーク(Pythonで言うところのFlask等)を用いてAPIサーバーを立ち上げるというのをよく聞きます

このAPIサーバーというものがフロント側からきたリクエストに対してビジネスロジックを加えてJSONでリスポンスを返すくらいのことはわかっているのですが、サーバーサイド側、データベース、Webサーバー等とどう関連しているのかいまいちピンと来ていません。(どなたかフロー図でご教授頂けると大変助かります。)

また、もし、このAPIサーバーというものにたいしてバックエンドの処理を機能ごとに呼び出せ、維持管理が楽になる?という側面がある場合、それはマイクロサービスといわれるアーキテクトとどう違うのでしょうか。

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

gentaro

2020/09/28 04:26

まずご自身でどこまで調べた上で、具体的にどこがわかなかったのか書きましょう。 最低限、Wikipediaとグーグルで検索したトップページに乗っている程度の事はご自身で確認してください。(この質問ではそれをやっているのかどうかもわかりません) ここで「○○とはなんぞや」と質問したところで、ググって出てくる大量の資料と同じ事が回答されたとして、それを既にあなたが読んでいたら、お互いに時間の無駄です。
guest

回答2

0

Laravel(API出力を主) + Vue.jsで解説します。

ご質問の内容を深く理解するにはMVCというものを理解する必要があるように感じます。MVCに関してはこちらをご覧ください。

以下のような仕様であると仮定します。

/posts/{id} // idは記事番号 /api/posts/{id} // idは記事番号

/posts/10にアクセスがあった時、Vue.jsが/api/posts/10へGET or POSTリクエストを行います。

Laravelでは、リクエストから記事番号を抜き出します。この場合では、記事番号が10のものをDBから取得して、整形して、JSON等の形式でレスポンスします。

その後、Vue.jsでスタイリングなどを行って表示します。

所々割愛していますがこのような流れになっています。

投稿2020/09/29 08:46

編集2020/09/29 08:49
kyoya0819

総合スコア10429

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

0

一応回答しておきます。

最近、フロント側でJSのフレームワーク(Vueやreact)を用いてシングルページアプリケーションを作り、
サーバーサイド側は簡易フレームワーク(Pythonで言うところのFlask等)を用いて
APIサーバーを立ち上げるというのをよく聞きます

APIサーバ自体の考え方が違うような気がします。
基本APIサーバを立ち上げるのは異なるサービスやソフトとの連携を行うためにつくられるもので
自システム内で収まるのであればAPIサーバを使用するメリットはありません。
(外部から操作できるのでデメリットのほうが大きいです)

このAPIサーバーというものがフロント側からきたリクエストに対してビジネスロジックを加えて
JSONでリスポンスを返すくらいのことはわかっているのですが

参照系APIの場合そうですが、更新系APIも存在します。

サーバーサイド側、データベース、Webサーバー等とどう関連しているのかいまいちピンと来ていません。
(どなたかフロー図でご教授頂けると大変助かります。)

システムによって構成は変わります。なので質問者様の方で自分に合った事案で検索してみて下さい。

また、もし、このAPIサーバーというものにたいしてバックエンドの処理を機能ごとに呼び出せ、

維持管理が楽になる?

もしこんなAPIサーバがあったら怖くて使えません。

先にも書きましたが基本APIサーバは異なるサービスやソフトとの連携を目的として使用します。
例えば
「財務会計のWebシステムと自社のシステムとの連携」
「自社HPの使用履歴をExcelにダウンロード」
「動画情報の検索を自分のHPで行いたい」
「地図情報サービスにの自社店舗情報を自動で送り更新する」
とかです。
これも全データに無条件にアクセスはできなくてAPIKeyなどを使い登録者の分だけのアクセスに限定したりします。
(他者に財務会計データ見られたら困るでしょ?)
「Web API」はあくまで自社のシステムの一部に外部との連携をhttps形式で行うための方式となります。

投稿2020/09/29 05:30

kuma_kuma_

総合スコア2506

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

退会済みユーザー

退会済みユーザー

2020/09/30 04:56 編集

> 自システム内で収まるのであればAPIサーバを使用するメリットはありません。 > (外部から操作できるのでデメリットのほうが大きいです) 今どきのWebサービスはSPA+APIサーバが主流となりつつあります。 非同期通信を活用することでページの再読み込みを減らしユーザ体験が向上するなどのメリットから上記が採用されているはずなので、この意見は間違いだと思います。
kuma_kuma_

2020/09/30 05:12 編集

私に考えではAPIサーバ自体バックドアの拡張でしかない認識です。 よって メインでできる事 > APIサーバでできる事の関係でないといけません。 非同期通信は確かに良いですがブラウザから内容の把握が容易になる弱点があります。(結局はAPIにさせるコマンドですからコピーされたらどうしますか?) せっかく今までの仕組みでセキュリティを保っていたのに安易に公開すべきではないと提言しているのです。(私レベルで解析できてしまいうんですよ?) もし非同期通信にこだわりセキュリティを強化するならすでにAPIの利便性から離れた状態になります。 自システム内で完結させたいのであればそこまでしてAPIにこだわる必要はないでしょ? 問い「SPA+APIサーバ」における欠点とは?
kyoya0819

2020/10/02 02:45

> 結局はAPIにさせるコマンドですからコピーされたらどうしますか? なんのコマンドですか?
kuma_kuma_

2020/10/02 03:59

> なんのコマンドですか? APIの設計にもよりますがとしか答えられませんが? それとも私が書いているコマンドに対する定義の事でしょうか? それなら「web API実行時におけるURLおよび付随するパラメータ」→「コマンド」という書き方です。 参照系の場合 たとえば今まではHTML形式で複合的に返し単純なデータ化できなかったのが API非同期処理にした場合JSON形式になる場合がほとんどでしょう。 その為ブラウザのネットワークを監視すればすぐに「このコマンドを送ればこの内容が取得できると」わかってしまいます。暗号化しておかないと生のJSONでとられてしまう事も考えられます。 対策しておかないとブラウザからのコマンドコピーだけで大量のデータ取得行われる可能性があります。 またパラメータ名からtable名field名がばれてしまう事も考え設計しなくてはなりません。 (SQLアタックの材料になるから) その対策はコマンド自体が判明する事は避けられない。 だができる限り対策を行い正規ルート以外のアクセスに関しては防ぎたいとなりますが、 この対策は手間がかかります。(また完全ではない) 普通のWebであればHTMLとして完成した状態なので余計な情報は消したり隠匿できたのが APIではその後の加工上どうしても付随の情報が付いてしまう。 またAPIは単機能に分かれますのでAPIコマンドをみるだけで機能が把握されてしまいす。 (単HTML上でも確かに見れコピーできますが対策を行う事は別の方法で可能だった) まとめると ・Web API を外部連携を想定していた場合 過度のセキュリティ保護を求めることができない。なぜなら利便性が低下するから。また異ソフト間でもデータをやり取りする目的の為相手側がそのような処理を行えない可能性がある。 ・Web API を外部連携せず自システムで活用を想定した場合 自社漏えい防止や個人情報保護の観点からセキュリティ保護をやめる事はできない ただいままでのWeb方式の仕組みと違いAPIはデータのやり取りがメインとなる為 APIにもセキュリティ保護を施す必要があるが手間が非常にかかる。 結果としていままでのWeb方式より多くのソース、作業量となりAPIの意味がなくなる可能性がある。 すみません > なんのコマンドですか? がどこを指すのかが判らずその後の「コピーされたら」の追記を長々書いています。 両方合わせてお返事になっていれば良いのですが
kyoya0819

2020/10/02 04:09

ありがとうございます。 > 暗号化しておかないと生のJSONでとられてしまう事も考えられます。 これの危険性については具体的にどのような攻撃があるとお考えでしょうか? また、「誰に」取られる可能性があるとお考えでしょうか?
kuma_kuma_

2020/10/02 04:34

暗号化については基本個人情報観点が大きいです。 「誰に」に対する可能性に関しては ・ブラウザハック等の手法により外部の人間から操作される可能性 ・内部の人間が取得する可能性 です。 攻撃手段に関しては ブラウザハックの手法はセキュリティソフト等で対策も可能ですが完全ではない。 またhttpsでも通信パケットから分析が可能です。(実際読み取れることを確認しています。) 内部の人間からですが結果として検索画面等で表示されますので完全ではないです。 ただ画面のコピーを1画面ずつ行い、その後の再編集等の手間(時間)をかけさせることで抑止にはなるかと思います。よくある家の防犯対策と同じ考え方です。 内部の人間によるAPIのコマンドコピー実行の場合JSON形式のダウンロードという簡単および大量に短時間で実行可能で専門知識が無くても行える方式なので、暗号化が必要と考えています。
kyoya0819

2020/10/02 05:12 編集

ブラウザハック = ブラウザをハッキング(クラッキング)しサイト閲覧の監視や悪意のあるスクリプトを実行するという認識で大丈夫でしょうか?
kuma_kuma_

2020/10/02 05:25 編集

> ブラウザをハッキング(クラッキング)し はい。その認識であっています。 私もそのつもりの内容で書いています。 実際私レベルでも作成可能です。(もちろん利用したことはありませんよ) そちらはセキュリティソフトに任せれば良いのですが 「通信パケットから分析」が厄介でWebを使うPCに入れる必要がないんですよね...
guest

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

まだベストアンサーが選ばれていません

会員登録して回答してみよう

アカウントをお持ちの方は

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
85.35%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問