RESTful API

RESTful API

Web上で使用される各種リソースをHTTP URIとして表し、これらのリソースをHTTPメソッド(ロード、受信など)と定義する.HTTP Method + Payloadの形で簡潔に表現することができる.

Payload
HTTPリクエストからサーバに送信されたデータを、箱詰めとして送信するデータ

RESTful APIを使用する理由

これはself-descriptivenessの特徴を持っているからです.
URIではGET/users、POST/beverages/1と同じ形式で表される.
URIを見るだけで何のAPIなのか分かりやすいです.
ただし、RESTful APIには既定の標準規則が存在しないため、開発者では既定の規則にデフォルトで従う.そのため、形が変わる可能性があります.

API設計規則

URI情報を明確に表現する.資源は主に名詞型を用いる.GET/users/show/1 -> GET users/1

リソースの動作:HTTPメソッド(GET/POST/DELETE)で表される.GET delete/user/1 -> DELETE /users/1

リソース間の関連付け:/リソース/一意ID/リレーショナルリソースGET /users/{user_id}/profile

ファイルの場合、URIにはファイル拡張子は含まれません.GET users/1/profile-photo.jpg ❌

URIの最後の文字で、/は含まれません.
後でリソースを追加する必要がある場合は、?が貼り付けられます./を最後に貼ると、雷索を放すことができません.

大文字およびunderbar(_)は使用されません.

Path Parameter

URI末尾に/idを加算すると、id値を有するデータを受信することができる.
GET http://10.58.4.1:8000/products

{
  "results": [
    {
      "id": 1,
      "name": "사리곰탕"
      "price: "1000원"
    }, 
    {
      "id": 2,
      "name": "신라면"
      "price: "800원"
    }, 
  ]
}

GET http://10.58.4.1:8000/products/2

{
  "results": [
    {
      "id": 2,
      "name": "신라면"
      "price: "800원"
    }, 
  ]
}

Query Parameter

SearchingGET /users?search=신라면

PaginationGET /products?offset=0&limit=100

OrderingGET /products?ordering=-id

FilteringGET /products?price=3000&name=신라면

Path Parameter vs Query Parameter

GET /products/3およびGET /products?id=3は同じ結果を示した.
どちらの方法を使えばよいのでしょうか.
勢いに乗って導く.
複数の条件にわたってデータをフィルタリングしたり、検索機能を実装したりする必要がある場合はquery parameterを使用することが望ましい.URIが長すぎる場合やフィルタリング、書き込みなどの機能が必要でない場合はpath parameterを使用するだけでよい.