DRF中处理非URL安全resource_id的Retrieve端点最佳实践

核心问题在于WSGI服务器（如Gunicorn、uWSGI）会自动将URL中的%2F解码为/，导致DRF无法获取完整的复合resource_id。以下是几种实用的解决方案：

1. 将resource_id作为查询参数传递 #

放弃把复合ID放在URL路径中，改用查询参数传递，示例请求：
GET /service/resources/?resource_id={customer_id}-{encoded_listing_id}

前端只需对listing_id做一次URL编码（将/转为%2F），后端直接从查询参数中获取完整的resource_id，不会被服务器拆分。

DRF视图示例：

from rest_framework.views import APIView
from rest_framework.response import Response
from your_app.models import ResourceModel
from your_app.serializers import ResourceSerializer

class ResourceRetrieveView(APIView):
    def get(self, request):
        resource_id = request.query_params.get('resource_id')
        if not resource_id:
            return Response({"error": "resource_id 必填"}, status=400)
        
        try:
            resource = ResourceModel.get(resource_id)
            return Response(ResourceSerializer(resource).data)
        except ResourceModel.DoesNotExist:
            return Response({"error": "资源不存在"}, status=404)

优点：实现简单，无需修改服务器配置，彻底规避路径编码问题；缺点：不符合部分REST路径参数的风格，但实用性极强。

2. 使用Base64URL编码处理listing_id #

对listing_id采用Base64URL编码（将普通Base64的+替换为-，/替换为_，去掉末尾的=），确保编码后的字符串无URL特殊字符，后端解码后再拼接成原始resource_id。

前端编码示例（JS）：

function encodeListingId(listingId) {
  const base64 = btoa(unescape(encodeURIComponent(listingId)));
  return base64.replace(/\+/g, '-').replace(/\//g, '_').replace(/=+$/, '');
}
// 拼接resource_id：customerId + "-" + encodeListingId(listingId)

DRF后端解码示例：

import base64
from rest_framework.views import APIView
from rest_framework.response import Response
from your_app.models import ResourceModel
from your_app.serializers import ResourceSerializer

class ResourceRetrieveView(APIView):
    def get(self, request, resource_id):
        try:
            customer_id, encoded_listing_id = resource_id.split('-', 1)
        except ValueError:
            return Response({"error": "resource_id 格式无效"}, status=400)
        
        # Base64URL解码
        try:
            padding = 4 - len(encoded_listing_id) % 4
            if padding != 4:
                encoded_listing_id += '=' * padding
            listing_id_bytes = base64.urlsafe_b64decode(encoded_listing_id)
            listing_id = listing_id_bytes.decode('utf-8')
        except:
            return Response({"error": "listing_id 编码无效"}, status=400)
        
        original_resource_id = f"{customer_id}-{listing_id}"
        try:
            resource = ResourceModel.get(original_resource_id)
            return Response(ResourceSerializer(resource).data)
        except ResourceModel.DoesNotExist:
            return Response({"error": "资源不存在"}, status=404)

优点：符合REST路径参数的风格；缺点：需要前后端配合完成编码解码，增加了少量复杂度。

3. 拆分路径参数（业务允许时） #

如果可以调整API设计，将customer_id和listing_id拆分为两个独立的路径参数，示例请求：
GET /service/resources/{customer_id}/{listing_id}/

DRF路由配置中，使用<path:listing_id>匹配包含/的路径片段：

from django.urls import path
from your_app.views import ResourceRetrieveView

urlpatterns = [
    path('service/resources/<str:customer_id>/<path:listing_id>/', ResourceRetrieveView.as_view()),
]

视图中拼接原始resource_id：

class ResourceRetrieveView(APIView):
    def get(self, request, customer_id, listing_id):
        resource_id = f"{customer_id}-{listing_id}"
        try:
            resource = ResourceModel.get(resource_id)
            return Response(ResourceSerializer(resource).data)
        except ResourceModel.DoesNotExist:
            return Response({"error": "资源不存在"}, status=404)

优点：无需编码解码，API设计更清晰；缺点：需要调整原有API路径，若已有前端依赖原路径则需同步修改。

4. 修改WSGI服务器配置（不推荐） #

部分WSGI服务器支持关闭%2F的自动解码，例如：

• Gunicorn：启动时添加参数 --decode-component false
• Nginx：在location块中设置 merge_slashes off; 并确保proxy_pass保留原始编码

但这种方式会影响整个服务的URL解析逻辑，可能引发其他端点的意外问题，除非能确保所有端点都不需要自动解码，否则不建议使用。

内容的提问来源于stack exchange，提问作者Chris Parker