[Improvement]: Honor `methods` property for entities backed by tables/views

[kliszaq]

What happened?

When I have a configuration that is read only - GET method on a rest api, then both swagger and /openapi endpoints still all of the methods. For example:

"entities": {
    "dab_adv2012-sales-currencyrate": {
      "source": {
        "object": "[Sales].[CurrencyRate]",
        "type": "View",
        "key-fields": [
          "CurrencyRateID"
        ]
      },
      "graphql": {
        "enabled": false
      },
      "rest": {
        "methods": [
          "Get"
        ],
        "enabled": true
      },
      "permissions": [
        {
          "role": "anonymous",
          "actions": [
            {
              "action": "Read"
            }
          ]
        }
      ]
    },

produces all the endpoints in swagger and open api. Expected: the endpoints are limited to the selected rest methods.

Version

0.8.52

What database are you using?

Azure SQL

What hosting model are you using?

Static Web Apps (SWA)

Which API approach are you accessing DAB through?

REST

Relevant log output

No response

Code of Conduct

• [X] I agree to follow this project's Code of Conduct

[Aniruddh25]

hi @kliszaq, Thank you for reporting this. It is by design as of now since the methods property only restricts the APIs for entities that are backed by stored procedures. If you think this should be supported for views and tables too, it can be an enhancement. Let us know. Thanks!

[kliszaq]

Hi @Aniruddh25 thanks for your reply. Indeed, IMHO open api endpoints documentor should reflect also tables and views in reference to the method property. I would say even more - the methods should also reflect the type of the view. Because how do you imagine PUT or DELETE for the view (exception is a view made of a single table without joins, aggregate functions, etc.) ? IMHO views related operations should be read-only. This means that the get on methods should only be allowed.

[Bysza]

@kliszaq, for views to accept CUD operations, quite a lot can be done, for example, instead-of triggers. I would leave the view updatability as a supported feature.

[Benjiiim]

hi @kliszaq, Thank you for reporting this. It is by design as of now since the methods property only restricts the APIs for entities that are backed by stored procedures. If you think this should be supported for views and tables too, it can be an enhancement. Let us know. Thanks!

I do think that this would be a great improvement indeed. The use case being to have the cleanest OpenAPI document possible to facilitate API import in APIM for example.

For read only entities declared as such through the methods property, that would mean not generating the put, patch and delete operations and not generating the useless _NoAutoPK and _NoPK components in the OpenAPI document.

[JerryNixon]

This solution does not account for the mixing of actions available across different roles for the same entity.

[JerryNixon]

Please see #2946