Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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

...

  • Some of our 'searching' endpoints are omitting parameters, it can confuse users if some valid search parameters are not taken into consideration
    Jira Legacy
    serverSystem JIRA
    columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
    serverId448ba138-230b-3f91-a83e-16e7db1deed1
    keyOLMIS-3857
    :
    • /api/facilities GET endpoint omits all other parameters if 'id' parameter is passed 
      Jira Legacy
      serverSystem JIRA
      columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
      serverId448ba138-230b-3f91-a83e-16e7db1deed1
      keyOLMIS-3704
    • /api/users GET endpoint omits all other parameters if 'id' parameter is passed 
      Jira Legacy
      serverSystem JIRA
      columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
      serverId448ba138-230b-3f91-a83e-16e7db1deed1
      keyOLMIS-3705
    • /api/catalogItems GET endpoint omits all other parameters if 'format' parameter is passed 
      Jira Legacy
      serverSystem JIRA
      columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
      serverId448ba138-230b-3f91-a83e-16e7db1deed1
      keyOLMIS-3706
  • We have /api/facilities/minimal GET endpoint which is returning facilities with only id and name properties
    Jira Legacy
    serverSystem JIRA
    columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
    serverId448ba138-230b-3f91-a83e-16e7db1deed1
    keyOLMIS-3858
    , it can be resolved by:
    • introducing limiting fields pattern and implement it in /api/facilities GET endpoint  
      Jira Legacy
      serverSystem JIRA
      columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
      serverId448ba138-230b-3f91-a83e-16e7db1deed1
      keyOLMIS-3707
  • 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)
    Jira Legacy
    serverSystem JIRA
    columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
    serverId448ba138-230b-3f91-a83e-16e7db1deed1
    keyOLMIS-3859
    . Here are 2 related tickets:
    Jira Legacy
    serverSystem JIRA
    columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
    serverId448ba138-230b-3f91-a83e-16e7db1deed1
    keyOLMIS-3231
    and
    Jira Legacy
    serverSystem JIRA
    columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
    serverId448ba138-230b-3f91-a83e-16e7db1deed1
    keyOLMIS-3232
    . It could  be resolved by:
    • replacing Swagger UI with something more native to Swagger i.e. API Console 
      Jira Legacy
      serverSystem JIRA
      columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
      serverId448ba138-230b-3f91-a83e-16e7db1deed1
      keyOLMIS-3708
       Q: do we have a better one?
  • Our PUT /api/{resource}/{id} endpoints do not allow creating objects with specified 'id' 
    Jira Legacy
    serverSystem JIRA
    columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
    serverId448ba138-230b-3f91-a83e-16e7db1deed1
    keyOLMIS-3860
  • We need to introduce expanded REST api pattern:  
    Jira Legacy
    serverSystem JIRA
    columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
    serverId448ba138-230b-3f91-a83e-16e7db1deed1
    keyOLMIS-3667
  • 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 
    Jira Legacy
    serverSystem JIRA
    columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
    serverId448ba138-230b-3f91-a83e-16e7db1deed1
    keyOLMIS-3723
  • 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 → 
      Jira Legacy
      serverSystem Jira
      columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
      serverId448ba138-230b-3f91-a83e-16e7db1deed1
      keyOLMIS-3772
  • 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: 
    Jira Legacy
    serverSystem JIRA
    columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
    serverId448ba138-230b-3f91-a83e-16e7db1deed1
    keyOLMIS-3709
  • Search parameters in some places are confuisng i.e. we have 'facility' instead of 'facilityId' or 'facilityCode'
    • Jira Legacy
      serverSystem JIRA
      columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
      serverId448ba138-230b-3f91-a83e-16e7db1deed1
      keyOLMIS-3482