This is a list of issues with REST implementation that are still not resolved. Here is Read the Docs page about REST design and OLMIS dev forum post. 

List is ordered so the issue with the highest priority that should be done first are on the top.

• Some of our 'searching' endpoints are omitting parameters, it can confuse users if some valid search parameters are not taken into consideration :
  • /api/facilities GET endpoint omits all other parameters if 'id' parameter is passed 
  • /api/users GET endpoint omits all other parameters if 'id' parameter is passed 
  • /api/catalogItems GET endpoint omits all other parameters if 'format' parameter is passed 
• We have /api/facilities/minimal GET endpoint which is returning facilities with only id and name properties , it can be resolved by:
  • introducing limiting fields pattern and implement it in /api/facilities GET endpoint  
• Swagger have problems with endpoints that can return or accept multiple types of data (i.e. /api/catalogItems can return application/json and text/csv content types) . Here are 2 related tickets: and . It could  be resolved by:
  • replacing Swagger UI with something more native to Swagger i.e. API Console  Q: do we have a better one?
• Our PUT /api/{resource}/{id} endpoints do not allow creating objects with specified 'id' 
• We need to introduce expanded REST api pattern:  
• In Requisition service we have api/requisitions/forConvert /api/requisitions/submitted endpoints and retrieving those requisitions should probably be done using GET /api/requisition/ endpoint 
• We should merge /api/{resource} GET endpoints with /api/{resource}/search endpoints in all places that it is possible and will not introduce problem with searching like with extraData property, we should fix them on the occasion, not in separate tickets:
  • /api/geographicZones/search
  • /api/lots/search
  • /api/requisitions/search
  • /api/requisitionTemplate/search
  • /api/transferProperties/search
  • /api/orders/search
  • /api/supervisoryNodes/search
  • /api/supplyLines/search
  • /api/stockAdjustmentReasons/search
  • /api/rights/search
  • /api/requisitionGroups/search
  • /api/programs/search
  • /api/facilities/search
  • /api/users/search
  • /api/users/rightSearch
  • /api/facilities/byBoundary → 
• We are still using '/print' endpoints
• Requisition resource is still using actions like submit/approve/skip, Here is a solution that we want to end up with: 
• Search parameters in some places are confuisng i.e. we have 'facility' instead of 'facilityId' or 'facilityCode'
  •