Why Pages are not always sufficient for Web Services

Every Page object in NAV 2009 can act as a web service. We know that and we love it. But there are cases where a Page object isn’t sufficient. Or at least a standard Page object isn’t. Let me explain some of these cases:

• Pages are used in RTC
• Page methods lack custom parameters
• Security

Pages are used in RTC

When using the Pages that are shipped with NAV you eventually will run into a situation where you don’t use all the fields that a certain Page contains. But every time that you call a Page web service, all the data in the unused fields is being transferred down the wire. This is overhead that should be avoided. And at the other hand it is also possible that a standard Page lacks some of the fields that you need.

Inevitably in both cases you have to modify the Page. But since Pages in the first place are mentioned for and used by the RTC, any modification to a Page will lead to a modified user interface in the RTC. This is probably not always a problem, however in my opinion Pages that are used for UI and Pages that are used for web services should be separated.

Page methods lack custom parameters

A Page that is being exposed as a web service offers basic methods like Create, CreateMultiple, Read, ReadMultiple, etc. These functions cannot be modified to add extra parameters.

Imagine that you want to update a record and suspend some checks, like the status check in table Sales Line. This is not possible using the basic Update function. Functions from source record of the Page are not exposed to the web service.

Unfortunately extension Codeunits are not a solution here. A function in an extension Codeunit takes the record as first parameter, but it is not possible to provide updated values with this parameter. In the code that is calling the function of an extension Codeunit you only have the possibility to provide the record key. The function then can perform extra actions, but uses data that is already saved in the database before.

Security

Pages follow the normal users and roles approach of NAV. The permissions are applied based on the used credentials, whether you use default credentials or custom credentials. And as long as you are the responsible person for the code that consumes the web services this is ok.

But when you don’t control the code that consumes your web services possible security threats occur. In case you are providing the Page web services and a third party is writing the code, then you don’t control their use of filters. Again, this is not a problem when they are allowed to read all data. But you are out of control when they are not allowed to read all data and it all depends on using filters. How would you know when the third party doesn’t apply the correct filters and gets data that is not mentioned for their eyes?

The only way to completely control this is to use Codeunits and XMLPorts instead of Pages. In a next post I will provide an example of using XMLPorts in web services.

Also, be careful with the basic functions of a Page web service. Again, if you don’t control the code make sure that the Page only provides the basic functions that you want to be available. If the web service only should be used for reading records, make sure that create, update and delete functions are not available at all. In a next post I will give some examples on how to achieve that.