Here are some of the resources I found helpful for learning to develop Dynamics NAV web service based applications.

C/AL Programming:

Introduction to CAL Programming
This provides a good overview of the basics of CAL programming, which can become necessary in building a web service applications when a custom codeunit or page extension is required.

Setting up Web Services:

Vjecko Web Service Recorded Session
Vjecko.com has a lot of detailed articles about web service programming, but this older post has a pdf and recorded session that shows how to expose and connect to web services from a .NET application. Unfortunately, he shows how to create Web Service references in .NET using the now-deprecated Web Refrence method (from .NET 2) instead of the more current Service Reference method.

Using Service Reference to Connect to Web Services
This explains how to use Service Reference, using code instead of XML web.config configuration, which I found difficult to configure. (Each time I updated the service reference, I would have to reconfigure the XML).

NAV Upgrade Process:

Migration to SQL Server from C/SIDE Database
In order to use web services, you don’t need to be using the Role Tailored Client, but you must be using the a SQL server based NAV database. Web Services can be configured and exposed using the Classic Client for SQL Server Databases.

Debugging Code Called by Web Services
C/AL code won’t necessarily execute the same as it did in the Classic Client when called as a Web Service. C/AL code called as web service execute in the NAV Server tier, instead of the client. Certain functions aren’t available for code running in the NAV Server, and some design changes need to be made (for example, CONFIRM dialogue boxes don’t make sense in the context of a web service). To debug the codeunits called through web services (or the Role Tailored Client), you will need to use Visual Studio.
More information.

Deploying a .NET Application:

Deploying to IIS After you’ve built a .NET application that consumes .NET web services, you’ll have to find a way to deploy it on your servers, or Azure. Connection strings can be used to specify different NAV servers for different environments (like development, QA, and prod).

One of the problems I faced in building a non-trivial application that consumed
NAV Web Services was figuring out how to “join” fields from different tables.
For example, when exposing a list of jobs from a job table which includes a
resource needed for the job, you might need more than just the resource id
that’s a field in the table: you might also need the resource name and
description. While this is easy to get for one record, what about when you
need a few hundred records in a table that has been dynamically filtered? When
exposing a Page as a web service, it’s easy to include the fields of the table
that the page is based on, but it’s less clear how to include fields from
another table.

Forum posts like this led me to believe that I couldn’t expose flow fields in a Page web service, and I would get exceptions when I tried to expose all the fields of a table. In fact, it’s perfectly possible to expose a flow field: it’s flow filters that don’t work with web services. But, I also didn’t want to modify the underlying [job] table to add a flow field, and didn’t see an easy way of adding a flow field to a Page. I tried “joining” the data in the C# application, but found network overhead made the application unusuably slow.

The solution to this problem was to use C/AL code to the Page to effectively create a lookup / flow field. This way, the data is “pre-joined” before leaving the NAV Server, which is fast and clean, but you didn’t modify any tables. Here’s how it’s done:

Step 1. Add a Field with SourceExpression Set to a Function Name

To start, we create a Page using the wizard that includes all of the fields of an underlying table. Then, we create manually add fields that will contain the lookup data from other tables. The text in the SourceExpression column will be the name of the function that populates this field.

Step 2. Create Function in the Page’s C/AL Code

With the Page field designer open, go to the functions tab of C/AL Globals form, and add a function with the name of the text in the SourceExpression column. Set the return type of the function with the “Locals” button, and a function trigger will appear in the C/AL code editor for your page. Add code to the body of the function trigger that will be called for each record to provide a value for the field.