REST API WITH PYTHON PHP NODEJS GO DJANGO LARAVEL LUMEN Examplesダウンロード-Python REST API WITH PYTHON PHP NODEJS GO DJANGO LARAVEL LUMEN Examplesソースコードのダウンロード

REST API WITH PYTHON PHP NODEJS GO DJANGO LARAVEL LUMEN Examples

その他のカテゴリー

1.0.0

ダウンロード

REST APIチュートリアル：REST APIおよびWhite-Label Servicesを構築し、API開発の正しい方法、REST APIの例

トレンドテクノロジーを使用してREST APIを構築します

ほとんどのトレンドテクノロジーでREST APIを作成 - PHP、Python、Go、Nodejs、およびほとんどのトレンドフレームワーク - Django、Laravel、Lumen、Gin

REST APIまたはRESTFUL APIとは何ですか？

RESTは、表現状態転送の頭字語です。 Restful APIは、HTTP要求を使用してデータにアクセスおよび変更するためのアプリケーションプログラムインターフェイス（API）のアーキテクチャスタイルです。そのデータを使用して、データ型を取得、配置、投稿、削除することができます。これは、リソースに関する操作の読み取り、更新、作成、削除を指します。詳細については

RESTベースのアーキテクチャで使用される主な機能は次のとおりです。

取得- リソースへの読み取り専用アクセスを提供します。
put-新しいリソースを作成します。
削除- リソースを削除します。
投稿- 既存のリソースを更新するか、新しいリソースを作成します。

アプリケーションは、特定の制約または原則を満たす必要があります。これらの原則について詳しく説明しましょう。

休息の原則

6つの基本原則があります。以下は、休息の6つの指針となる原則です。

STATELESS：クライアントからサーバーに送信されたリクエストには、完全に理解するために必要なすべての必要な情報が含まれています。それは、URI、クエリストリングパラメーター、ボディ、またはヘッダーの一部になる可能性があります。 URIはリソースを一意に識別するために使用され、ボディは要求リソースの状態を保持します。サーバーによって処理が実行されると、ヘッダー、ステータス、または応答本体を介して適切な応答がクライアントに送信されます。
クライアントサーバー：クライアントをサーバーから分離する均一なインターフェイスがあります。懸念を分離すると、複数のプラットフォームでユーザーインターフェイスの移植性を改善し、サーバーコンポーネントのスケーラビリティを向上させるのに役立ちます。
均一なインターフェイス：アプリケーション全体で均一性を得るために、RESTは次の4つのインターフェイス制約を定義しました。
```
  Resource identification
  Resource Manipulation using representations
  Self-descriptive messages
  Hypermedia as the engine of application state
```
キャッシュ可能：より良いパフォーマンスを提供するために、アプリケーションはしばしばキャッシュ可能になります。これは、サーバーからの応答を暗黙的または明示的にキャッシュ可能またはキャッシュできないものとしてラベル付けすることによって行われます。応答がキャッシュ可能として定義されている場合、クライアントキャッシュは将来の同等の応答の応答データを再利用できます。また、古いデータの再利用を防ぐのにも役立ちます。
層状システム：層状システムアーキテクチャにより、コンポーネントの動作を制限することにより、アプリケーションをより安定させることができます。このアーキテクチャは、負荷分散を可能にし、スケーラビリティを促進するための共有キャッシュを提供します。階層化されたアーキテクチャは、各レイヤーのコンポーネントが次の即時層を超えて相互作用できないため、アプリケーションのセキュリティを強化するのにも役立ちます。
コードオンデマンド：コードオンデマンドはオプションの制約であり、使用されていません。クライアントコードまたはアプレットを、アプリケーション内で使用するインターフェイスを介してダウンロードおよび拡張できるようにします。本質的に、独自のコード構造に依存しないスマートアプリケーションを作成することにより、クライアントを簡素化します。

REST APIとは何か、そして効率的なアプリケーションを提供するために気にする必要があるものがわかったので、すべてのトレンドテクノロジーとFrameoWRKSを使用して、より深く潜り、REST APIを構築するプロセスを見てみましょう。

SOAPとどのようにREST APIが違うのですか？

RESTおよびSimple Object Access Protocol（SOAP）は、Webサービスを呼び出すためのさまざまな方法を提供します。 RESTはアーキテクチャスタイルであり、SOAPはXMLベースのメッセージ交換の標準通信プロトコル仕様を定義します。 RESTアプリケーションは石鹸を使用できます。

Restful Webサービスは無国籍です。 RESTベースの実装はSOAPに比べて簡単ですが、REST Web Servicesインターフェイスを説明する標準的なルールセットがないため、ユーザーはコンテキストとコンテンツを渡すことを理解する必要があります。 RESTサービスは、モバイルなどの制限されたプロファイルデバイスに役立ち、既存のWebサイトと簡単に統合できます。

SOAPには、RESTサービスの設計よりもメインコードモジュールを接続する低レベルのインフラストラクチャコードを意味する、より少ない配管コードが必要です。 Webサービスの説明言語は、サービスのメッセージ、バインディング、操作、および場所を定義するための共通のルールセットを説明しています。 SOAP Webサービスは、非同期処理と呼び出しに役立ちます。

高性能REST APIを構築する方法は？そしてベストプラクティス

これらは、REST APIを開発する際に考慮する必要があるいくつかのポイントです。

ペイロードサイズを減らして制限します
キャッシュを有効にします
十分なネットワーク速度を提供します
偶発的な呼び出し、減速、虐待を防ぎます
パッチオーバープットを使用してみてください
ロギング、監視、アラートを有効にします
ページネーションを有効にします

1-ペイロードサイズを減らして制限します

応答データの非常に大きなペイロードは、要求の完了、その他のサービスコールを遅くし、劣化性のパフォーマンスに影響を与えます。ご存知のように、現在の注文とは対照的に、顧客のすべての注文を返却しているので、パフォーマンスの劣化に対処する必要があります。

GZip Compressionを使用して、ペイロードサイズを縮小できます。これにより、Webアプリ（クライアント側）での応答のダウンロードサイズが小さくなり、アップロード速度または一部のエンティティ（注文）の作成が増加します。 Web APIでDeflate compressionを使用できます。または、Accect-EncodingRequestヘッダーをGZIPに更新することができます。

2-キャッシュを有効にします

キャッシュは、APIのパフォーマンスを改善する最も簡単な方法の1つです。頻繁に同じ応答を返すリクエストがある場合、その応答のキャッシュバージョンは追加のサービスコール/データベースクエリを回避するのに役立ちます。キャッシュを使用して、特に新しいデータの更新が発生した場合、キャッシュ内のデータを定期的に無効にするときに確認する必要があります。

しかし、それはあなたがキャッシュを使用するとき、どこで使用するかを混乱させるかもしれませんか？

お客様が自動部品の注文を行いたいとし、アプリは一部の自動パーツAPIに呼び出してパーツ価格を取得します。応答（部品価格）は毎週（@午前1時）に1回しか変化しないため、それまでの残りの時間は応答をキャッシュできます。これにより、同じパーツ価格を返すために毎回新しい電話をかけることができなくなります。同様のケースキャッシュを使用して、追加の通話やリクエストを避けることができます。

3-十分なネットワーク速度を提供します

遅いネットワークは、最も堅牢に設計されたAPIのパフォーマンスを低下させます。信頼できないネットワークは、ダウンタイムを引き起こす可能性があり、それにより、組織がSLA、利用規約、および顧客に行った可能性のある約束に違反する可能性があります。適切なネットワークインフラストラクチャに投資することが重要です。そうすれば、目的のレベルのパフォーマンスを維持できます。これは、十分なクラウドリソースとインフラストラクチャを活用および購入することで実現できます(example: in AWS, allocate the proper # of EC2 instances, use a Network Load Balancer) 。また、大量のバックグラウンドプロセスがある場合は、リクエストのブロックを避けるために、個別のスレッドでそれらを実行します。また、ミラーやコンテンツ配信ネットワーク（CDN）を使用して、グローブのさまざまな部分の周りでより速くリクエストを提供することもできます。

4-偶発的な呼び出し、減速、および虐待を防止します

エンジニアがAPIを呼び出してローカルアプリケーションのループで実行する場合、APIが悪意を持って意図的であるか、反対にないDDOS攻撃に苦しむ状況を持つことができます。トランザクションを測定し、 monitoring the number of how many transactions occur per IP Address, or per SSO/JWT Token (if the customer/calling app is authorized before calling the API)ことで、これを回避できます。

レート制限するこの方法は、APIを遅くする過度の要求を減らし、偶発的なコール/実行に対処し、悪意のあるアクティビティを積極的に監視および特定するのに役立ちます。

5-パッチオーバープットを使用してみてください

エンジニア間の一般的な誤解であり、パッチ操作が同じ結果をもたらします。リソースの更新に似ていますが、それぞれが更新を異なる方法で実行します。リソース全体に更新を送信して、リソースを更新します。パッチ操作は、更新が必要なリソースのみに部分的な更新を適用します。結果として、ペイロードが少なくなり、規模のパフォーマンスが向上するインパッチコールが発生します。

   Pro-Tip: Even though PATCH calls can limit the request size, you should note that it is not Idempotent. 
    Meaning, it is possible that a PATCHcan yield different results with a series of multiple calls. 
    So, you should carefully and deliberately consider your application for using PATCH requests, 
    and make sure that they are idempotently implemented if needed. If not, use PUT requests.

6-ロギング、監視、アラートを有効にします

これはおそらくここで読む最も重要なヒントの1つです。このリポジトリから学ぶべきことが1つある場合、それはこれであるべきです！これについての交渉はありません。

ログ、監視、および警告を発揮するのは、エンジニアが問題になる前に問題になる前に診断し、修正するのに役立ちます。多くのAPI（Express/ノードベース、Java、Go）には、次のようなものを評価するための事前定義されたエンドポイントがあります。

 `/health`
`/metrics`

ロギングが有効になっておらず、潜在的な問題が発生している場合、起源を追跡することはできません。特定のリクエストで問題が発生している場所です。

監視が有効になっていない場合、いくつかの問題やエラーが発生している頻度で分析的な観点からはわかりません。その後、可能な解決策を考えることができなくなります。

そして…顧客（またはさらに悪いことに、顧客）がそれを報告するまで、アラートを有効にしていない場合、問題があるかどうかはわかりません。

7-ページネーションを有効にします

ページネーションは、複数の応答からコンテンツのバケツを作成するのに役立ちます。この種の最適化は、顧客に転送/表示されるデータを保存しながら、応答を改善するのに役立ちます。結果の複雑さを軽減するのに役立つ応答を標準化、セグメント、制限することができ、顧客が要求したもののみに対して応答/結果を提供することにより、全体的な顧客体験を改善できます。

結論

APIは驚くべきものであり、適切に最適化され、パフォーマンスのために強化された場合、ビジネスと顧客に素晴らしいエクスペリエンスを提供するのに非常に強力になる可能性があることを知っています。ビジネス要件と顧客の期待は常に時間とともに進化します。そして、責任あるエンジニアとして、私たちの目標を達成し、それを超えるのに役立つのは、パフォーマンスの方法でAPIを構築する方法を決定するのに依存しています。

これらのヒントは氷山の一角にすぎず、一般的な設定ですべてのAPIに適用されます。特定のAPIおよびユースケース、対話するサービス、呼び出される頻度、呼び出される場所などに応じて、これらのヒントをさまざまな方法で実装する必要があります。