Create view method - HTML encoded space character difference

Question

I have used two methods to create views: one through the Portal UI and one through the API.

In the former, I use the Create View button on the hosted feature layer item page. This replaces the space characters (HTML encoded %20) in my view title with underscores.

For example, it generates the REST URL: https://services.arcgis.com/.../arcgis/rest/services/Hosted_Feature_Layer_View_Title/FeatureServer/9 In the latter, I use the FeatureLayerCollection Manager method create_view(name="Hosted Feature Layer View Name"). This time it replaces the space characters with the HTML-encoded value

For example:

https://services.arcgis.com/.../arcgis/rest/services/Hosted%20Feature%20Layer%20View%20Title/FeatureServer/9

I found this to be an issue, because I overwrite a hosted feature layer, which requires me to drop my views and then recreate them after overwriting. I have web maps with layers depending on these views that break when that URL changes (between spaces or underscores).

I was able to fix the URL by opening the content JSON of the web map.

As I build out our management tools using the API, we will eventually settle on the API method to creating views. But as we are developing and multiple people are touching these hosted layers, this can cause issues.

AlexanderSt__John · Answer

I agree that underscores are preferrable.

I have been using spaces in all item titles for readability, but the views could be an exception, since they are entirely "internal" to Portal: i.e. none of our users are going to search for or open a view.

Thanks for your input.

EarlMedina · Answer

What is your proposed solution to this problem?  Personally, I prefer the UI version that replaces spaces with underscores. It gets away from the problem of URL encoding. My general opinion is spaces should be avoided whenever possible. I don't have much advice for you other than propose that you get your team to agree on certain naming conventions. The other thing I would suggest is logging a bug with Esri Support to match behavior between UI/API view creation. I do think you've identified some valid, problematic behavior here.