URLconf 中的格式后缀模式
为 Web API 使用 URL 文件扩展名以提供特定媒体类型端点是一种常见模式。例如，使用 'http://example.com/api/users.json' 提供 JSON 格式的表示。
若在 API 的 URLconf 每个条目中添加格式后缀模式，容易出错且违背 DRY 原则，因此 REST framework 提供了一个快捷方式，用于将这些模式添加到 URLConf 中。
format_suffix_patterns
签名 ：format_suffix_patterns(urlpatterns, suffix_required=False, allowed=None)
返回一个 URL 模式列表，在提供的每个 URL 模式后追加格式后缀模式。
参数：
- urlpatterns ：必需。一个 URL 模式列表。
- suffix_required ：可选。布尔值，指示 URL 中的后缀是可选还是必需。默认为
False，即后缀默认是可选的。 - allowed ：可选。有效格式后缀的列表或元组。若未提供，则使用通配格式后缀模式。
示例 ：
from rest_framework.urlpatterns import format_suffix_patterns
from blog import views
urlpatterns = [
path('', views.apt_root),
path('comments/', views.comment_list),
path('comments//', views.comment_detail)
]
urlpatterns = format_suffix_patterns(urlpatterns, allowed=['json', 'html']) 使用 format_suffix_patterns 时，必须确保在对应的视图中添加 'format' 关键字参数。例如：
@api_view(['GET', 'POST'])
def comment_list(request, format=None):
# 做一些事情...或者对于基于类的视图：
class CommentList(APIView):
def get(self, request, format=None):
# 做一些事情...
def post(self, request, format=None):
# 做一些事情...可以通过 FORMAT_SUFFIX_KWARG 设置修改所用的 kwarg 名称。
另外要注意，format_suffix_patterns 不支持深入 include URL 模式。
与 i18n_patterns 一起使用
如果使用 Django 提供的 i18n_patterns 函数，以及 format_suffix_patterns，应确保 i18n_patterns 函数作为最终或最外层函数应用。例如：
urlpatterns = [
…
]
urlpatterns = i18n_patterns(
format_suffix_patterns(urlpatterns, allowed=['json', 'html'])
)带查询参数的格式
格式后缀的一种替代方案是将请求格式包含在查询参数中。REST framework 默认提供此选项，并且在可浏览的 API 中用于在不同的可用表示之间切换。
要使用其简短格式选择表示，可使用 format 查询参数。例如：http://example.com/organizations/?format=csv。
可以使用 URL_FORMAT_OVERRIDE 设置修改此查询参数的名称。将值设置为 None 可禁用此行为。
关于 REST 架构风格的说明
网络社区中似乎存在一种观点，认为文件扩展名不是 RESTful 模式，而应始终使用 HTTP Accept 头代替。
这其实是一种误解。例如，Roy Fielding 在讨论查询参数媒体类型指示符与文件扩展名媒体类型指示符的相对优势时，曾有过以下观点：
“这就是为什么我总是更喜欢扩展名。无论是哪种选择，都与 REST 无关。” — Roy Fielding，REST 讨论邮件列表
此引文未提及 Accept 头，但它明确表明应将格式后缀视为一种可接受的模式。