Uploaded image for project: 'OpenNMS'
  1. OpenNMS
  2. NMS-8194

Return an HTTP 303 for PUT/POST request on a ReST API is a bad practice



    • Bug
    • Status: Resolved (View Workflow)
    • Blocker
    • Resolution: Fixed
    • Meridian-2015.1.0, 17.0.0
    • 18.0.0, Meridian-2016.1.0
    • Architecture, REST
    • Security Level: Default (Default Security Scheme)
    • None


      Based on what I read about design patterns for ReST APIs on several web pages (here is one example: http://www.restapitutorial.com/lessons/httpmethods.html), it seems like a POST request should return 201 with a Location header on a successful response, and a PUT request should return either 200 or 204. They should NEVER return a 303 unless you want to FORCE the client to perform a GET request, which I think it is not required on any of the OpenNMS ReST end points, especially on Requisitions because of NMS-7872.

      A little bit of history. When the Requisitions ReST API was introduced, the whole requisition was returned as part of a response of a PUT/POST request. Then, that was changed by returning a 303 with a Location header. The problem is that this is EXACLY the same thing in terms of a Web Browser, or any well implemented web client, as the Location will always going to be followed no matter if you need the data or not. So, that is basically doing the same wrong thing differently. It has to be OPTIONAL, the retrieval of the updated data for the client (NOT MANDATORY).

      Also the rest of the return codes are not consistent, and different rules are used which is not theoretically correct.




            agalue Alejandro Galue
            agalue Alejandro Galue
            0 Vote for this issue
            1 Start watching this issue