REST API拉取数据同时更新DB应使用GET还是PUT请求

• 先掰扯清楚两个方法的核心语义：PUT是给客户端用来主动改资源的——调用方得把要更新的完整内容塞在请求里发过来，服务端拿到之后把对应位置的资源全量替换掉，整个请求的核心目的就是"写"。但你这个接口从根上是给前端拿当前播放歌曲数据的，更新数据库那步，既不是前端要求你做的，要更新的歌曲名也不是前端传给你的，是你服务端自己调Spotify接口拉完数据之后，顺手存到库里的内部操作，跟PUT的适用场景半毛钱关系都没有。
• 很多人揪着"GET不能有副作用"说事，其实是对规范的误读。HTTP规范里说GET最好是"安全"的，这里的安全指的是这个请求不会触发客户端预期之外的资源变更——比如你不能写个GET接口，别人一调用就把用户账号删了，这才是违反安全约定的。但你这个更新DB的动作，对调用接口的前端来说完全是透明的，前端既不知道你要更新库，也没要求你更新，纯粹是你服务端自己为了同步状态做的内部缓存/持久化，根本不算违反GET的语义。
• 真换成PUT反而全是麻烦：第一是语义混乱，不管是前端调接口的人，还是后面接盘维护代码的人，看到PUT第一反应就是"这个接口要我传要更新的内容"，结果你这个接口啥参数都不用传，光返回数据，平白增加理解成本；第二是HTTP整个生态对GET和PUT的处理逻辑完全不一样，比如缓存代理默认会缓存GET响应、浏览器可能会预加载GET请求，但绝对不会主动碰PUT这类写方法，你硬把拉数据的接口改成PUT，平白丢了HTTP层的优化能力，纯纯得不偿失。

你现在的代码唯一可以调整的点是错误处理逻辑：如果更新数据库不是什么强一致性要求的核心步骤，更新失败的时候其实没必要直接返回406错误，正常把歌曲信息返回给前端，打个错误日志后续排查就行——当然这个是业务逻辑层面的选择，跟用不用GET没关系。

提问中附的实现代码 #

class GetCurrentSong(APIView):
    def get(self, request):

        dict_song_info = get_song_from_spotify(user_session=self.request.session.session_key)

        if 'Error' in dict_song_info:
            return Response({dict_song_info['Error_Type']: dict_song_info['Error']}, status=dict_song_info['Status'])     

        # Update song name in database
        try:
            self.update_song_info_in_db(dict_song_info['name'])
        except Exception as ex:
            return Response({'Storage Error': 'Caanot persist current song info to database'}, status=status.HTTP_406_NOT_ACCEPTABLE)

        return Response(dict_song_info, status=status.HTTP_200_OK)

额外提一句：要是后面你要单独做一个"手动触发服务端同步最新歌曲到数据库"的接口，那个接口才需要考虑用POST，当前这个以返回数据为核心目标的接口，老老实实⽤GET就对了。

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