フロントエンドとバックエンドのデータ連携

クライアントとサーバー間の通信は、HTTPプロトコルを介してリクエストを送信し、JSON形式などでデータを返すプロセスで構成されます。以下に現代的な実装例を示します。

クライアントサイドの実装

// frontend/src/api/resourceApi.js
export async function requestResource(targetUrl) {
    try {
        const res = await fetch(targetUrl, {
            method: 'POST',
            headers: {
                'Content-Type': 'application/json',
                'X-App-Token': 'secure_key_88',
                'X-Client-Type': 'web'
            },
            body: JSON.stringify({
                filter_id: 202,
                threshold: 8
            }),
            params: new URLSearchParams({
                mode: 'active',
                lang: 'ja'
            })
        });
        if (!res.ok) throw new Error('通信エラーが発生しました');
        return await res.json();
    } catch (err) {
        console.error('リクエスト失敗:', err);
        return null;
    }
}

サーバーサイドの実装

# backend/core/handlers.py
from django.http import JsonResponse
from django.views.decorators.csrf import csrf_exempt

@csrf_exempt
def process_incoming_data(request):
    # カスタムヘッダーの取得
    app_token = request.META.get('HTTP_X_APP_TOKEN')
    client_type = request.META.get('HTTP_X_CLIENT_TYPE')
    print(f"認証トークン: {app_token}, クライアント: {client_type}")

    return JsonResponse({
        'code': 200,
        'message': '処理成功',
        'payload': {}
    })

# backend/core/settings.py (CORS設定例)
CORS_ALLOW_HEADERS = [
    'x-app-token',
    'x-client-type',
    # ... その他の許可ヘッダー
]

DRF（Django Rest Framework）の環境構築

DRFはDjangoの公式サポートプラグインとして提供されており、RESTful APIの開発を効率化します。インストールと登録は以下の手順で行います。

• ターミナルで依存関係をインストール: pip install djangorestframework
• settings.py の INSTALLED_APPS に 'rest_framework' を追加し、アプリケーションを有効化します。

APIインターフェースの定義

API（Application Programming Interface）とは、異なるシステム間でのデータ交換を約束する通信仕様のことです。主な構成要素は4つです：URLエンドポイント、HTTPメソッド、リクエストパラメータ、レスポンス形式。

通常のWebページはHTMLドキュメントを返しますが、APIは構造化されたデータ（主にJSON）を返すため、機械可読な通信経路として機能します。

RESTful規範に則ったCBV実装

Class-Based View（CBV）を用いると、HTTPメソッドごとに専用の関数を定義でき、コードの再利用性と整理が容易になります。1つのビュークラスでコレクションリソースと個体リソースの両方を処理できます。

# backend/config/urls.py
from django.urls import path, include
urlpatterns = [
    path('v1/', include('core.resources.urls')),
]

# backend/core/resources/urls.py
from django.urls import path
from . import views
urlpatterns = [
    path('materials/', views.MaterialController.as_view(), name='material-list'),
    path('materials//', views.MaterialController.as_view(), name='material-detail'),
]

# backend/core/resources/views.py
from django.views import View
from django.http import JsonResponse

class MaterialController(View):
    http_method_names = ['get', 'post', 'put', 'patch', 'delete']

    def get(self, request, *args, **kwargs):
        return JsonResponse({
            'status': 0,
            'message': '成功'
        })

RESTful設計の重要な基準

URL設計のルール

• 通信の安全性を確保するため、HTTPSプロトコルを標準採用します。
• エンドポイントは /api/ で識別し、バージョン管理を行う場合は /v1/ や /v2/ をプレフィックスに使用します。
• URLには動詞を含めず、リソース名（名詞）のみを配置します。例: /articles/（一覧）、/articles/123/（個別）。
• 認証や検索など、CRUD操作に該当しない場合は例外パス（例: /login/）を使用します。
• 一覧取得時はクエリパラメータでフィルタリングやソートを指定します（例: ?sort=-created_at&limit=10）。

HTTPメソッドの使い分け

• GET: リソースの取得。一覧はコレクションを返し、個別ID指定は単一オブジェクトを返します。
• POST: リソースの新規作成。配列で複数件の同時作成も可能です。
• PUT: リソースの完全上書き更新。送信データにはすべての必須フィールドを含める必要があります。
• PATCH: リソースの部分更新。送信データは変更したいフィールドのみで構成できます。
• DELETE: リソースの削除。ID指定で1件または複数件の削除を実行し、通常はステータスメッセージのみを返します。

レスポンスデータの構成

HTTPステータスコード（2xx成功、4xxクライアントエラー、5xxサーバーエラーなど）はプロトコルレベルで定義されます。アプリケーションレベルでは、独自のカスタムステータスコードを付与し、フロントエンドの分岐処理を補助します。

• 0: 正常処理完了
• 1: 処理エラー（詳細メッセージを付与）
• 2: データ不存在

レスポンスボディにはメタ情報と実際のデータ構造を含めます。メディアファイルはURL文字列で参照します。

{
    "code": 0,
    "message": "完了",
    "data": [
        {
            "title": "技術設計書",
            "thumbnail": "https://cdn.example.com/imgs/th_404.png"
        }
    ]
}

CBVの内部実行フローとPyCharmデバッグ

as_view() の動作原理

DjangoのWSGIアダプタがリクエストを解析し、request オブジェクトにラッピングします。CBVでは as_view() がクラスをコールアブルな関数に変換します。この関数内部でクラスインスタンスが生成され、dispatch() メソッドが適切なHTTPハンドラ（get, postなど）にルーティングします。

# django/views/generic/base.py (概念抜粋)
class View:
    @classmethod
    def as_view(cls, **init_kwargs):
        def view(request, *args, **kwargs):
            self = cls(**init_kwargs)
            self.setup(request, *args, **kwargs)
            if not hasattr(self, 'request'):
                raise AttributeError(...)
            return self.dispatch(request, *args, **kwargs)
        
        view.view_class = cls
        view.view_initkwargs = init_kwargs
        return view

アンダースコアで始まる属性（例: _internal_cache）は、モジュール内でのみ使用されることを示す慣習です。

PyCharm デバッグ操作ガイド

• Resume Program: 次のブレイクポイントまで実行を継続。
• View Breakpoints: 現在のプロジェクト内にあるすべての停止地点を一覧表示。
• Mute Breakpoints: 既存の停止地点を一時無効化（再有効化可能）。
• Show Execution Point: 現在停止中のコード行にカーソルを強制移動。
• Step Over: 1行ずつ実行。関数呼び出しには深入りせず、次の行へ進みます。
• Step Into: 1行ずつ実行。関数呼び出しが存在する場合、その内部処理に進入します。
• Step Out: 現在の関数内処理を完了させ、呼び出し元まで抜けます。