2022幎10月14日·2分で読めたす

トップ REST API むンタビュヌの質問ず回答

この蚘事では、REST API の面接で最もよく聞かれる質問に぀いお説明し、開発者が開発者ずしお就職の面接に勝぀こずができるように準備したす。

トップ REST API むンタビュヌの質問ず回答

クラりド コンピュヌティング やマむクロサヌビス ベヌスのアヌキテクチャを含むいく぀かの開発は、RESTful API によっお可胜になりたした。圌らは、オンラむン コミュニケヌションずコンピュヌティングをシンプルなものずしお描いおきたした。したがっお、すべおの開発者は、 REST ずは䜕か、REST が どのように機胜するか、その利点、および時代に遅れずに぀いおいくための安党なサヌビスを䜜成する方法を理解する必芁がありたす。圌らは、スケヌラブルで保守が簡単な゜リュヌションの䜜成を支揎し、むンタヌネットの力のおかげで補品を䞖界䞭に届けるこずができるため、倚くの䌁業は REST を理解しおいる開発者を奜みたす。

RESTful API 関連の面接の質問に備えるにはどうすればよいですか?

REST API むンタビュヌ䞭に RESTful Web サヌビスに関する最も頻繁な REST API むンタビュヌの質問、および Spring MVC フレヌムワヌクを䜿甚しお構築された JAX-RS ラむブラリヌおよび RESTful Web サヌビスに関する問い合わせは、以䞋のセクションに蚘茉されおいたす。面接に参加したり、面接のスケゞュヌルを蚭定したりする前に、蚀及されおいるすべおの REST API 面接の質問に備えるこずが重芁です。

レストずは

Representational State Transfer を説明する REST は、HTTP プロトコルで確立された Web サむト アプリの開発を担圓したす。 REST は、Web サむト関連の有甚性がそれを信じるために付加しなければならないいく぀かのルヌルを指定したす。この提案により、サヌバヌずナヌザヌの間で暙準化された HTTP メ゜ッドが送信を仮想的に送信するこずが保蚌されたす。

REST API ずは䜕ですか?

RESTful API は、2 ぀のコンピュヌタヌ システム間で安党なオンラむン情報亀換を行いたす。さたざたなアクティビティを完了するために、 ビゞネス アプリケヌション の倧郚分は、他の内郚および倖郚プログラムずデヌタを亀換したす。たずえば、内郚の䌚蚈システムが埓業員情報を倖郚の銀行システムず共有しお絊䞎明现を生成する堎合などです。この情報は個人的なものであり、REST API ゜フトりェア暙準は安党で効率的で信頌できるものであるため、REST API を䜿甚しお実行できたす。

RESTful API は、䜕らかの方法で REST にリンクされおいる API ずしお知られおいたす。すべおのデヌタは REST API のリ゜ヌスず芋なされ、(URI) ず呌ばれる正確な暙準定数単䜍によっお決定されたす。 Twitter API は、ナヌザヌがアクセスしお取埗できるリ゜ヌスずしおツむヌトを䜜成したす。 Twitter API を䜿甚するず、ナヌザヌは簡単にツむヌトを投皿できたす。

REST の原則は䜕ですか?

クラむアントサヌバヌでは、コンシュヌマヌずサヌバヌの間で送信するために䜿甚される䞀連の応答が可胜です。どちらも盞互に応答を送受信できたす。このクラむアント サヌバヌ方匏の明確なビゞョンにより、䞡方の勢力が盞互に支揎を受けずに掻動できるようになりたす。

レむダヌドシステム

クラむアントず API サヌバヌの間のレむダヌはサヌバヌです。これらの異なるサヌバヌは、スパムの怜出やパフォヌマンスの向䞊など、いく぀かのタスクを実行したす。クラむアントずアプリケヌション プログラミング むンタヌフェむス (API) サヌバヌの間で送信されるメッセヌゞは、レむダヌを远加たたは削陀しおも圱響を受けたせん。これは、REST (representational state) がモゞュラヌ アヌキテクチャを䜿甚しおいるためです。

統䞀むンタヌフェヌス

クラむアントずサヌバヌは、すべおの通信に垞に同じプロトコルを䜿甚する必芁がありたす。このプロトコルは HTTP REST です。すべおのアプリケヌションが同じ蚀語を䜿甚しおデヌタを芁求および提䟛するため、統䞀されたむンタヌフェヌスによっお統合が容易になりたす。

ステヌトレス

ステヌトレス通信では、サヌバヌは送信枈みの応答の蚘録を保持したせん。すべおの応答には、取匕を完了するために必芁な完党な入力が含たれおいたす。サヌバヌの負荷ずメモリ䜿甚量を枛らすこずで解釈を改善したす。たた、情報が䞍完党であるためにリク゚ストが倱敗する可胜性を排陀したす。

キャッシュ可胜

クラむアントは、リ゜ヌスがキャッシュ可胜かどうかを瀺すサヌバヌからのサヌバヌ応答を䜿甚しお、任意のリ゜ヌスをキャッシュしおパフォヌマンスを向䞊させるこずができたす。 REST には、次のオプションの条件も含たれおいたす。

コヌドオンデマンド

API の応答には、ナヌザヌが実行できる実行可胜コヌドを含めるこずができたす。したがっお、クラむアント アプリケヌションは独自のバック゚ンドでコヌドを実行できたす。

AJAX ず REST の違いは䜕ですか?

AJAX ず REST の違いは次のずおりです。

AJAX****䌑みXMLHttpRequest オブゞェクトは、サヌバヌに芁求を送信するために Ajax で䜿甚されたす。ただし、 JavaScript のコヌドは、珟圚のペヌゞを動的に倉曎するための答えを提䟛したす。リ゜ヌスの䜿甚率は、URI 構造ず芁求/応答パタヌンにずっお重芁です。 REST によっお䜿甚されたす。 Ajax は、ペヌゞをリロヌドせずにナヌザヌ むンタヌフェむスを動的に曎新できるテクノロゞのグルヌプです。ナヌザヌは、REST ゜フトりェア アヌキテクチャ スタむルを䜿甚しお、サヌバヌからデヌタたたは情報を芁求できたす。 Ajax は、サヌバヌずナヌザヌの間の非同期通信を排陀したす。 REST は、サヌバヌずナヌザヌ間の通信を芁求したす。

マむクロサヌビス アヌキテクチャはどのように機胜したすか?

クラりド アプリケヌションを開発するためのアヌキテクチャ手法は、マむクロサヌビスず呌ばれたす。各アプリケヌションは倚数のサヌビスで構成されおおり、各サヌビスは個別のプロセスで実行され、API を介しお他のサヌビスず察話したす。 「マむクロサヌビス アヌキテクチャ」ずしお知られるアプリケヌションの䜜成方法は、時間の経過ずずもにベスト プラクティスになりたした。マむクロサヌビス アヌキテクチャのコンポヌネントは、ビゞネスのニヌズに基づいおいたす。

  • クラむアント

リク゚ストは、さたざたなデバむスを䜿甚しお倚数のナヌザヌから送信されたす。

  • ID プロバむダヌ

ナヌザヌたたは顧客の身元を確認し、セキュリティ トヌクンを提䟛したす。

  • API ゲヌトりェむ

クラむアント リク゚ストは API Gateway 経由で凊理されたす。

  • 静的コンテンツ

システムのすべおの玠材は、静的コンテンツに含たれおいたす。

  • 管理

障害を特定し、ノヌド間でサヌビスのバランスをずりたす。

  • サヌビス発芋

マむクロサヌビス間の通信経路を決定するためのツヌル。

  • コンテンツ配信ネットワヌク

プロキシ サヌバヌず関連するデヌタ センタヌの分散ネットワヌク。

  • リモヌトサヌビス

IT デバむスのネットワヌクに保存されおいる情報は、リモヌト サヌビスを利甚しおリモヌトからアクセスできたす。

REST でサポヌトされおいる HTTP メ゜ッドは䜕ですか?

APIをより安党にする
組み蟌みの認蚌モゞュヌルで、実運甚を想定したRESTサヌビスを保護する。
認蚌を远加

REST HTTP でサポヌトされおいるメ゜ッドは次のずおりです。

  • GET - Web サむトや API で最も広く䜿甚されおいるメ゜ッドで、GET は特定のデヌタ サヌバヌからリ゜ヌスを受け取りたす。
  • POST - POST メ゜ッドを介しお、デヌタが API サヌバヌに送信され、リ゜ヌスが曎新されたす。サヌバヌがデヌタを受信するず、それを HTTP 芁求本文に栌玍したす。
  • PUT - リ゜ヌスを䜜成および曎新するためにデヌタを API に送信したす。
  • DELETE - 名前が瀺すように、このメ゜ッドは特定の URL のリ゜ヌスを削陀するために䜿甚されたす。
  • OPTIONS - サポヌトされおいる手法に぀いお詳しく説明したす。

HEAD - リク゚スト URL に関するメタデヌタが返されたす。単䞀のレコヌドの芳点から状況を調べおみたしょう。埓業員番号 1 の埓業員のレコヌドがあるずしたす。次のアクティビティはそれぞれ異なるこずを瀺したす。

POST - すでに䜜成されおいる埓業員 1 の情報を取埗しおいるため、これは適甚されたせん。

GET - これは、RESTful Web API を介しお埓業員の情報を取埗するために䜿甚され、埓業員番号は 1 になりたす。

PUT - RESTful Web API を䜿甚しお、埓業員番号 1 を反映するように埓業員の情報を曎新するために PUT が䜿甚されたす。

DELETE - この関数は、埓業員番号 1 の埓業員の情報を削陀するために䜿甚されたす。

PUT ず POST の違いは䜕ですか?

PUT ず Post の違いは次のずおりです。

  • PUT - 提䟛された (Uniform Resource Identifier) URI でファむルたたはリ゜ヌスを正確か぀具䜓的に識別したす。 PUT は、既存のファむルがそのナニフォヌム リ゜ヌス識別子 (URI) に存圚する堎合、それを倉曎したす。 PUT は、既にファむルが存圚する堎合はファむルを圢成したす。さらに、PUT は冪等性があり、ファむルの䜿甚頻床にはただ圱響しないこずを瀺唆しおいたす。
  • POST - 個別の統䞀リ゜ヌス識別子 (URI) にデヌタを送信し、そこにあるリ゜ヌス ファむルが芁求を管理するこずを期埅したす。この時点で、Web サむト サヌバヌは、遞択されたファむルのコンテキストでデヌタを䜿甚しお䜕ができるかを決定できたす。さらに、POST 戊略はべき等ではありたせん。぀たり、2 回以䞊䜿甚するず、新しいファむルの生成が再開されたす。

モノリシック SOA ずマむクロサヌビス アヌキテクチャの違いは䜕ですか?

モノリシック アプリは、開発速床が非垞に遅く、盞互接続された分割できないナニットで構成されおいたす。小芏暡で最小限に接続されたサヌビスが SOA を構成したすが、これも開発が制限されおいたす。

マむクロ サヌビスは、非垞に小さく、疎に接続されたスタンドアロン サヌビスであり、反埩的な開発サむクルが迅速です。

URIずは

Uniform resource identifier は URI ず呌ばれたす。 REST の URI は、Web サヌバヌのリ゜ヌスを指定する文字列です。各リ゜ヌスには個別の URI があり、HTTP 芁求で䜿甚されるず、クラむアントはそれをタヌゲットにしおアクションを実行できたす。アドレッシングは、URI を䜿甚しおリ゜ヌスにトラフィックを送信するプロセスです。

URI の圢匏は次のずおりです。

<プロトコル>://<サヌビス名>/<リ゜ヌスタむプ>/<リ゜ヌスID>

URIには2぀のタむプがありたす

1. URL - その堎所からのリ゜ヌスの取埗に関する情報は、Uniform Resource Locator で入手できたす。

URL には、ネットワヌクのホスト名 (sampleServer.com) ずコンテンツぞのパス (/samplePage.html) に関する情報が含たれおおり、プロトコル (FTP、HTTP など) で始たりたす。たた、怜玢条件を指定するこずもできたす。

2. URN - 独特で耐久性のある名前を䜿甚するこずにより、統䞀されたリ゜ヌス名がリ゜ヌスを識別したす。

むンタヌネット䞊のリ゜ヌスの堎所は、必ずしも URN によっお指定されるわけではありたせん。これらは、リ゜ヌスを識別するずきに䜿甚する他のパヌサヌのモデルずしお機胜したす。

URN がドキュメントを識別するたびに、「リゟルバヌ」を䜿甚しおすばやく URL に倉換し、ダりンロヌドできるようにしたす。

RESTful Web サヌビスの機胜は䜕ですか?

䜜りながらRESTを実践
コヌド䞍芁で、デヌタモデル・゚ンドポむント・ロゞックを備えた本栌的なREST APIバック゚ンドを䜜る。
AppMasterを詊す

これらの機胜は、すべおの RESTful Web サヌビスに存圚したす。

  • クラむアント サヌバヌ通信モデルは、サヌビスの基盀です。
  • このサヌビスは、HTTP プロトコルを䜿甚しお、デヌタ/リ゜ヌスのフェッチ、ク゚リの実行、およびその他のタスクを実行したす。
  • 「メッセヌゞング」は、クラむアントずサヌバヌ間の通信に䜿甚される方法です。
  • サヌビスは、URI を䜿甚しおリ゜ヌスにアクセスできたす。
  • これは、クラむアントの芁求ず応答が他に䟝存しないずいうステヌトレスの考え方に準拠しおいるため、必芁なデヌタが取埗されるずいう完党な確実性を提䟛したす。
  • 同じタむプの繰り返し芁求に察するサヌバヌ呌び出しを枛らすために、これらのサヌビスはキャッシングの考え方も採甚しおいたす。
  • これらのサヌビスは、SOAP サヌビスを䜿甚しお REST アヌキテクチャ パタヌンを実装するこずもできたす。

HTTP ステヌタス コヌドずは䜕ですか?

HTTP ステヌタスで䜿甚される暙準コヌドは、確立されたサヌバヌ タスクの完了ステヌタスに察応しおいたす。たずえば、HTTP ステヌタス 404 は、芁求されたリ゜ヌスがサヌバヌにないこずを瀺したす。

HTTP ステヌタス コヌドを芋お、その意味を理解したしょう。

  • 200 - OK、成功は明らかです。
  • 201 - POST たたは PUT リク゚ストがリ゜ヌスを正垞に䜜成するず、応答コヌドは 201 - CREATED になりたす。 location ヘッダヌを䜿甚しお、新しく生成されたリ゜ヌスに URL を返したす。
  • 304 - 条件付き GET リク゚ストの堎合、ネットワヌク垯域幅を節玄するためにステヌタス コヌド 304 NOT MODIFIED が䜿甚されたす。応答本文は無効でなければなりたせん。日付、堎所、およびその他の情報は、ヘッダヌに含める必芁がありたす。
  • 400 - BAD REQUEST は、デヌタの欠萜や怜蚌ミスなどの無効な入力が提䟛されたこずを瀺したす。
  • 401 - FORBIDDEN は、管理者暩限なしでアクセスを削陀するなど、䜿甚されおいるメ゜ッドにナヌザヌがアクセスできないこずを瀺したす。
  • 404 - ERROR は、芁求されたメ゜ッドが芋぀からないこずを瀺したす。
  • 409 - CONFLICTS メ゜ッドが実行されるず、重耇する゚ントリの挿入など、競合する問題があるこずを瀺したす。
  • 500 - INTERNAL SERVER ERROR コヌドは、メ゜ッドの実行䞭にサヌバヌが䟋倖をスロヌしたこずを瀺したす。

RESTful Web サヌビスの欠点を教えおください。

RESTful Web サヌビスの欠点は次のずおりです。

  • アシスタントはステヌトレスの抂念に固執するため、RESTful Web サヌビスのセッションを維持するこずはできたせん。
  • セキュリティず保護の制限は、REST にずっお必須ではありたせん。䞀郚のプロトコルは、安党保護のために䜿甚されたす。これを行うず、SSL/TLS 認蚌など、遞択する保護および安党基準を決定する際に䜿甚できる譊告が衚瀺されたす。

SOAP ず REST を区別したすか?

SOAP ず REST の違いは次のずおりです。

石鹞****䌑みSOAP ず呌ばれるプロトコルを䜿甚しお Web サヌビスを実装したす。 REST は、Web サヌビスを開発するためのアヌキテクチャヌ蚭蚈パタヌンですSOAP が提䟛するガむドラむンは、厳密に遵守するこずを目的ずしおいたす。 REST は基準の抂芁を瀺しおいたすが、完党に準拠する必芁はありたせん。 SOAP クラむアントずサヌバヌはより密接に関連しおいるため、この点で厳密な契玄を持぀デスクトップ プログラムに匹敵したす。 REST クラむアントはブラりザより適応性が高く、必芁な通信暙準に準拠しおいる限り、サヌバヌの蚭蚈に䟝存したせん。クラむアントずサヌバヌ間の XML 転送のみが SOAP でサポヌトされおいたす。 XML、JSON、MIME、Text などの耇数のデヌタ型が REST によっお提䟛されたす。 SOAP 読み取りはキャッシュできたせんREST 読み取りク゚リはキャッシュ可胜サヌビス むンタヌフェむスは、リ゜ヌス ロゞックを公開するために SOAP によっお䜿甚されたす。リ゜ヌス ロゞックは、URI を䜿甚しお REST を䜿甚しお公開されたすSOAP が遅いREST の方が速いプロトコルであるため、SOAP は独自のセキュリティ プロトコルを確立したす。 REST は、実装プロトコルに基づいたセキュリティ察策のみを行いたす SOAP は頻繁に遞択されるわけではありたせんが、ステヌトフルなデヌタ転送ずより高い信頌性が必芁な堎合に䜿甚されたす最近では、スケヌラビリティず保守性が向䞊するため、REST が開発者に奜たれるこずがよくありたす。

HTTP レスポンスのコア コンポヌネントを構成するものは䜕ですか?

モバむルからRESTをテスト
ネむティブiOS/Androidアプリを、れロから䜜らずAPIに接続する。
モバむルアプリを䜜成

HTTP 応答には、次の 4 ぀の䞻芁なコンポヌネントがありたす。

  • 応答ステヌタス コヌド - リ゜ヌス リク゚ストに察するサヌバヌのステヌタス コヌドが衚瀺されたす。䟋: クラむアント偎の゚ラヌは 400 で衚され、成功した回答は 200 で衚されたす。
  • HTTP バヌゞョン - HTTP プロトコルのバヌゞョンは、HTTP バヌゞョンによっお瀺されたす。
  • 応答ヘッダヌ - 応答メッセヌゞのメタデヌタは、このセクションに含たれおいたす。デヌタは、コンテンツの長さ、皮類、応答日、サヌバヌの皮類などを提䟛するために䜿甚できたす。
  • 応答本文 - サヌバヌが実際に返したリ゜ヌスたたはメッセヌゞは、応答本文に含たれおいたす。

WebSocket ず REST の違いは䜕ですか?

以䞋に、 WebSocket ず REST の違いをいく぀か瀺したす。

REST は CRUD 操䜜に基づいおいたすが、WebSocket は基本的なトランスポヌト メカニズムである゜ケットずポヌトの抂念に基づいた䜎レベルのプロトコルです。

RESTful アプリケヌションは、動詞ず HTTP に基づいお操䜜を蚭蚈する必芁がありたすが、WebSocket では、アプリケヌションの䞋䜍レベルの詳现である IP アドレスずポヌト情報を䜿甚する必芁がありたす。 WebSocket はステヌトフル プロトコルですが、REST はステヌトレス プロトコル䞊に構築されおいたす。぀たり、クラむアントもサヌバヌもお互いを認識する必芁はありたせん。

氎平方向にスケヌリングできる HTTP に基づく REST ずは察照的に、WebSocket 接続は単䞀サヌバヌ䞊で垂盎方向にスケヌリングできたす。 REST ベヌスの通信は比范的高䟡ですが、WebSocket 通信は安䟡です。

REST にトランスポヌト局セキュリティ (TLS) を実装できたすか?

はい、できたす REST でのクラむアント/サヌバヌ間の通信は TLS を䜿甚しお暗号化されたす。これにより、サヌバヌを確認する機胜もナヌザヌに提䟛されたす。これは Secure Socket Layer (SSL) に取っお代わるため、ナヌザヌずサヌバヌ間の安党な通信の圢匏です。 HTTPS は Secure Socket Layer (SSL) および Transport Layer Security (TLS) ずうたく機胜するため、RESTful Web サヌビスを䜜成するずきに圹立ちたす。ここで、REST が䜿甚するプロトコルの偎面に関係しおいるこずに泚意するこずが重芁です。したがっお、安党保護は REST のプロトコルに䟝存しおいたす。

POST メ゜ッドで送信できるペむロヌドの最倧サむズは?

REST流でリ゜ヌスをモデリング
PostgreSQLのテヌブルを芖芚的に蚭蚈し、スキヌマから本番甚バック゚ンドを生成する。
バック゚ンドを䜜成

ポスト方匏で運べるペむロヌドの倧きさは理論䞊無制限です。ただし、ペむロヌドが倧きいほど垯域幅を消費し、凊理に時間がかかり、サヌバヌの応答性に圱響するこずに泚意しおください。

JAX-RS API に存圚する䞻芁な泚釈を䞀芧衚瀺する

  • パス - これは、REST リ゜ヌスの盞察 URI (Uniform Resource Identifier) パスの詳现を瀺したす。
  • GET - リク゚スト メ゜ッドのこの指定子は、HTTP GET に察応したす。 GET ク゚リを凊理したす。
  • POST - リク゚スト メ゜ッドのこの指定子は、HTTP POST に察応したす。圌らは POST 問い合わせに察凊したす。
  • PUT - リク゚スト メ゜ッドのこの指瀺子は、HTTP PUT リク゚ストに察応したす。圌らはPUTの問い合わせを扱いたす。
  • DELETE - HTTP DELETE に䜿甚されるリク゚スト メ゜ッドの指定子ずしお定矩されたす。これらは DELETE 芁求を凊理したす。
  • HEAD - リク゚スト メ゜ッドのこの指定子は、HTTP HEAD に察応したす。圌らはHEADの問い合わせに察凊したす。
  • PathParam - 開発者は、この URI (Uniform Resource Identifier) パス パラメヌタヌを䜿甚しお、リ゜ヌス クラス/メ゜ッドの URI からパラメヌタヌを抜出できたす。
  • QueryParam - リ゜ヌス クラス/メ゜ッドは、開発者がこの URI (Uniform Resource Identifier) ク゚リ パラメヌタヌを䜿甚しお URI (Uniform Resource Identifier) から抜出したこれらのク゚リを䜿甚できたす。
  • プロデュヌス - 䜜成され、ナヌザヌに返信ずしお送信される MIME リ゜ヌス プレれンテヌションがここで指定されたす。
  • 消費 - これは、サヌバヌがナヌザヌからそれらを受け取るずきに受け入れるか䜿甚する MIME リ゜ヌス プレれンテヌションの詳现を瀺したす。

Spring で RestTemplate を定矩する

ナヌザヌが RESTful サヌビスにアクセスするための䞻芁なクラスは、RestTemplate ず呌ばれたす。 REST制限を利甚しお、サヌバヌずの通信を行いたす。これは、JdbcTemplate や HibernateTemplate など、Spring が提䟛するさたざたなテンプレヌト セクションに盞圓したす。 RestTemplate はメ゜ッドに (Uniform Resource Identifier ) URI テンプレヌト、URI (Uniform Resource Identifier) パス パラメヌタ、芁求/応答の皮類、芁求オブゞェクトなどを䜿甚しお通信する機胜を提䟛したす。GET などの HTTP メ゜ッドの高レベルの実装の詳现を提䟛したす。 、POST、PUT など。

Spring 4.3 のこのセクションでは、@GetMapping、PutMapping、@PostMapping などのよく䜿甚されるアノテヌションを提䟛したす。その前に、Spring は @RequestMapping 解釈を提䟛しお、䜿甚されるメ゜ッドを指定したす。

@RequestMapping の甚途は䜕ですか?

  • リク゚ストは、アノテヌションを䜿甚しお特定のハンドラ メ゜ッドにマップされたす。

  • Dispatcher Servlet は、Spring ですべおの受信 Web アプリケヌション ルヌティングを管理したす。リク゚ストハンドラヌを䜿甚するこずで、リク゚ストを受信したずきにリク゚ストを凊理するコントロヌラヌを決定したす。 @Controller アノテヌションを持぀すべおのクラスは、Dispatcher Servlet によっおスキャンされたす。

    コントロヌラヌのメ゜ッドずクラス内で定矩される @RequestMapping アノテヌションは、リク゚スト ルヌティング プロセスに䞍可欠です。

Web API を開発たたはテストするためのツヌルたたは API を列挙する

ロヌカルからクラりドぞ移行
AppMaster Cloud、AWS、Azure、Google Cloudなどのクラりドにアプリをデプロむする。
今すぐデプロむ

Postman、Swagger などのさたざたなツヌルを䜿甚しお、RESTful Web サヌビスをテストできたす。 Postman には、゚ンドポむントに芁求を送信する機胜、JSON たたは XML に倉換できる応答を衚瀺する機胜、ヘッダヌやク゚リ パラメヌタヌなどの芁求パラメヌタヌや応答ヘッダヌを分析する機胜など、倚くの機胜がありたす。 Postman ず同様に、Swagger は倚数の機胜ず ゚ンドポむント を文曞化する機胜を提䟛したす。 Jmeter などのツヌルを䜿甚しお、API のパフォヌマンスず負荷をテストするこずもできたす。

キャッシングずは

サヌバヌ応答がキャッシュされるず、同じ応答を再床生成する代わりに、必芁に応じお新しいコピヌを利甚できるように保存されたす。この手法は、サヌバヌの負担を軜枛するだけでなく、パフォヌマンスずスケヌラビリティも向䞊させたす。応答は、クラむアントによっおのみ、短時間だけキャッシュできたす。

リ゜ヌスのヘッダヌず簡朔な説明が以䞋に含たれおいるため、キャッシング手順でそれらを識別できたす。

  • リ゜ヌスが䜜成された日時
  • 通垞、最新の情報を保持するリ゜ヌス曎新の日時
  • キャッシュ制埡のヘッダヌ
  • キャッシュされたリ゜ヌスが動䜜を停止する日時
  • リ゜ヌスがフェッチされたずきの開始点を確立する幎霢

REST API を孊ぶのに最適なリ゜ヌスは䜕ですか?

Web サむトやモバむル アプリケヌションを開発 するための REST API を孊習するための利甚可胜なリ゜ヌスが倚数ありたす。䞊䜍5䜍は以䞋の通り。

RESTful Web サヌビス

API を䜿甚するアプリケヌションの開発を開始するには、Leonard Richardson による RESTful Web Services wonder ず呌ばれるこのガむドブックが、この点で非垞に圹立ちたす。特に初心者で、Representational State Transfer (REST) Web サむト サヌビスの基本を理解したい堎合。このリ゜ヌスは、Representational State Transfer (REST) がどのように機胜するか、および他の耇数の重芁な Web 関連サヌビスを䟋ずずもに明らかにしたした。これは特定のプログラミング蚀語に基づいおいるわけではないため、RESTful API の理解はどのプログラミング蚀語にも限定されたせん。

REST API チュヌトリアル

REST API チュヌトリアルは、本や読曞家でない堎合に Representational State Transfer (REST) を孊習するための優れたオンラむン リ゜ヌスです。このリ゜ヌスは、REST を最初から最埌たで孊習するのに圹立ち、すべおの基本的な偎面をカバヌしおいたす。このチュヌトリアルは、Representational State Transfer (REST) の玹介から始たり、HTTP 関連の戊略ず知識などに関する䟋のパスをたどりたす。

REST API 蚭蚈ルヌルブック

これは、Representational State Transfer (REST) ガむダンスの優れたリ゜ヌス ブックでもありたす。本の著者である Mark Masse は、REST API を䜿甚しおアプリケヌションを構築するのに圹立った経隓ず戊略を䌝えおいたす。このリ゜ヌスでは、アプリケヌション URI を考案するためのプラクティス、HTTP ヘッダヌを介しおメタデヌタを送信するためのアプロヌチ、および䜿甚できるメディアの皮類に぀いお説明したした。さらに、HTTP の送信メ゜ッドず応答ステヌタス コヌドの蚭蚈にどのように革新を加えるか。

API デベロッパヌ りィヌクリヌ ニュヌスレタヌ

API デベロッパヌ りィヌクリヌ ニュヌスレタヌずいう玠晎らしいリ゜ヌスがありたす。 Web ベヌスのアプリケヌションずモバむル アプリの API 技術、構造、拡匵、およびアヌキテクチャに非垞に集䞭しおいるため、RESTful API を孊習するための最新のリ゜ヌスです。このニュヌスレタヌは、開発者、プロゞェクト マネヌゞャヌ、アヌキテクト向けに特別に䜜成されおいたす。

安心しおください

これは、Java ず呌ばれる 1 ぀のプログラミング蚀語の経隓がある人にずっおは幞運な、オヌプン゜ヌスの REST テスト メディアです。このリ゜ヌスは、RESTful API プロセスのテストず怜蚌の手順を容易にしたす。たた、REST-Assured は、耇雑な反応をテストするためのボむラヌプレヌト コヌドを䜜成する必芁性を根絶し、BDD 構文を支揎したす。

手短に

結論ずしお、䞊蚘の蚘事では REST API むンタビュヌの質問を共有しおいたす。 RESTful API の知識を必芁ずする同様の仕事に応募しようずしおいる、たたは応募したこずがある人のための REST API 面接の質問をすべおカバヌしおいたす。これらは、面接で面接官があなたに尋ねるこずができる最も䞀般的な質問です。たた、最終面接を受ける前に、前述のリ゜ヌスを確認しおください。

さらに、Web サむト アプリケヌションたたはモバむル アプリを構築する堎合は、AppMaster が最終的な遞択肢になりたす。これは、コヌディングの経隓や知識がなくおも 、ドラッグ アンド ドロップ で簡単にあらゆる皮類のアプリケヌションを構築できる ノヌコヌド プラットフォヌムです。今日のお埗な情報をチェックしおください。

始めやすい
䜕かを䜜成する 玠晎らしい

無料プランで AppMaster を詊しおみおください。
準備が敎ったら、適切なサブスクリプションを遞択できたす。

始める
トップ REST API むンタビュヌの質問ず回答 | AppMaster