Hi Rick,
I am now starting to work on adding a REST API to an existing WWWC App. It's been a while, but the app was created via the DO Console utility if I recall, so I think adding a REST Process to an existing app is the path/option I need to take.

I think I would like to use the existing Virtual Directory so the REST API access is //ExistingVirtual/Customer.csvc, but not sure if that's the best approach.

I noticed this warning in the docs:
Overwrite Warning When you use the Add Process Class Wizard and install to an existing virtual directory you are overwriting existing templates and sample pages. If you don't want to override any existing templates, it's best to generate to a new virtual and physical directory and then simply add the scriptmap to your existing application's web.config file, and change the application paths in your yourApp.ini file.

Well, I want the existing app to continue to function as is, so I'm not sure I understand the above warning. Also, if I need to revert back to before, I have backed up the WebConnectionProjects\WebApp\Deploy and \Web folders. How would I backup the IIS Virtual settings? Or, is that part of the WebConnectionProjects\WebApp\Web folder backup?

How would you approach the REST API access? Use Existing Virtual: ExistingVirtual/Customer.csvc
or maybe create a new sub-virtual, like ExistingVirtual/API/Customer.csvc
or something different, like NewVirtualAPI/Customer.csvc

Still trying to wrap my head around this. But having fun, I think! 😃

TIA,
Steve

In the latest version of Web Connection (ie. v8) adding a new process class does not have the option to create a new virtual. It just creates the process class and adds the script map to the existing application.

• New Process Wizard - Step 2 - Configure a Scriptmap

+++ Rick ---

OK, thanks Rick!

Hi Rick,
Hope you've had a great holiday.

Please take a look at this link. It still shows the Create Virtual when creating a REST Service. May need to be updated.

https://webconnection.west-wind.com/docs/Walk-Through-Tutorials/Step-by-Step-Creating-a-JSON-REST-Service/Step-1-Create-a-new-REST-Service.html

Thanks again!

Hi Rick,
So far, this is going great! Very easy! I have started with my Customer table. I have a question about the field case/names. Very often I have used an underscore in field names such as last_name, first_name, etc... Will these field names be an issue for a REST API? My hope is to use the API internally but also allow 3rd Parties to use it as well.

The JSON field names being returned from the customer query are of course all lower case currently. I know about the PropertyNameOverrides utility, but that's not really for field names with underscores, right? I guess I could modify the queries to remove the underscore from the returned field names, but I hope that won't be necessary. Is it a problem to leave everything in lower case and to use the underscores?

What are your thoughts here?

Thanks,
Steve

Underscores are legal for property names during serialization. In fact anything is legal for JSON since text is string encoded (in "prop" quotes). What you want to avoid is things that don't translate into property names (in FoxPro or otherwise) - things that start with numbers are not legal as a Fox property for example. Underscores are legal in property names, but dashes are not as are a host of other special characters (quotes, parenthesis, comma etc.). If you're starting with FoxPro fields or Properties, that's not going to be an issue since it has to work to serialize in the first place... this is more of a concern if object structures are created externally or by another service.

Ideally you'd want Camel Casing for JSON output - ie. no dashes and mixed case prop names - but that's convention not a requirement. You can return whatever you want, but you'll want to try and be consistent. Use all camel case, or all lower, or lower with underscores etc. If your format is this_prop where words or concepts are separated by _ that's fine. Just try and be consistent.

If it's a big mess (due to Fox field size restrictions or outdated naming conventions) the alternative is to use SQL commands to rename the fields to what you want them to be using the AS fieldname clause or by custom objects that are populated from your underlying data either fixed classes or dynamic objects (using CREATEOBJECT("EMPTY") and ADDPROPERTY()). In essence, you're then creating DTO (data transfer objects) that are used for communication only and you translate to and from the underlying data. If you build a public API that'll be widely used then it's worth to go through the trouble of making sure the data formatting is nice - otherwise, making it work and keeping it simple is probably a better approach.

+++ Rick ---

Thanks Rick. Yes, using the SQL AS fieldName is what I was thinking, if necessary. There are not that many field names with underscores. I think I will leave it as-is, at least for now. I don't think it will be a widely used API.

I really appreciate your feedback.

Steve