API

apiはサーバとデータベースのエントリとして機能します.アプリケーションとデバイス間の通信がスムーズで、すべての接続が標準化されていることを確認します.apiを使用すると、実装の詳細を理解することなく、製品またはサービスが相互に通信でき、アプリケーション開発を簡素化し、時間とコストを節約できます.

REST

REST構造スタイルに適したWeb APIをREST APIと呼ぶ.
RESTは、ウェブサイトのコンテンツ(テキスト、画像、ビデオ)やデータベース内のコンテンツなどをリソースとして理解し、各リソースに固定URI(Uniform Resource Identifier)を付与するリソースガイド構造(ROA:Resource Oriented Architecture)である.このリソースのCRUD動作は、HTTPの基本コマンドであるPOST、GET、PUT、DELETEにより処理される.

誕生する

2000年にロイ・フェルティン博士の学位論文で最初に紹介された.ロイ・フィルディンはHTTPの主な著者の一人であり、当時のWeb(HTTP)設計の優秀性よりも正常に使用できないことを惜しみ、Webの長所を最大限に活用できるアーキテクチャでRESTを発表した.

特長

HTTP Web標準を使用しているため、Web上で使用されている既存のインフラストラクチャを使用することができます.

Uniform Interface

URIとして指定されたリソースを統一的で限定されたインタフェースで成長させるアーキテクチャスタイル.

Stateless

ステータスなし.作業状態情報は個別に保存および管理されません.APIサーバは、受信した要求を簡単に処理するだけで、サービスの自由度が向上し、サーバ上の不要な情報を管理することができず、実装が簡素化される

Cacheable

最新の変更ラベルまたはE-Tagを使用してキャッシュを実装

自己記述(自己表現構造)

REST APIメッセージを表示するだけで操作を簡単に理解できます.

クライアント-サーバ構造

RESTサーバはAPIを提供しているため,クライアントはユーザ認証やコンテキスト(セッション,ログ確認情報)などの構造を直接管理し,役割ごとに明確な区別があるため,クライアントとサーバが開発する必要があるコンテンツはより明確であり,相互依存性はより小さい.

階層構造

複数の階層に分けることができ、セキュリティ、負荷バランシング、暗号化層を追加し、構造をより柔軟にし、エージェント、ゲートウェイなどのネットワークベースの中間メディアを使用することができます.

REST API設計

URIは、情報を表すリソース

を必要とする.

リソースの挙動は、HTTPメソッド(GET、POST、PUT、DELETE)として表現される

URI設計

スラッシュ(/)階層関係を表す

URI最後の文字で、/

ハイフネーション(-)可読性の向上

下線()

を使用しない

小文字

ファイル拡張子はURIに含まれません

リソース間の関連表現

/리소스명/리소스 ID/관계가 있는 다른 리소스명
ex) GET : /users/{userid}/devices (일반적으로 소유 ‘has’의 관계를 표현할 때)

HTTP応答状態コード

ステータスコードは、200個のクライアントが正常に201個のクライアント要求を実行してリソースを作成することを意味する.リソースが正常に作成された場合(POSTを使用して)400クライアントの要求が無効な場合、401クライアントは許可されていません(ログイン)保護されたリソースが要求された場合、クライアントが要求したリソースが403ユーザIDに関係なく、301クライアントが要求したリソースのURIが変更された場合、使用するレスポンスコード500サーバに問題が発生した場合に使用される
📑 reference

soapapi-ウィキペディア

http://recordingbetter.com/drf/2017/07/11/REST%EC%9D%98-%ED%83%84%EC%83%9D-%EB%B0%B0%EA%B2%BD

https://www.slipp.net/wiki/pages/viewpage.action?pageId=12878219

https://meetup.toast.com/posts/92