RFC AspNetCore: Simple Urls

[Daniel-Svensson]

The current Uri schema of "NAMESPACE-TYPENAME.csv/binary/MethodName" is quite long/verbose and can be simplified.

Some of the current issues are that

• uris are long which means that
  • in analytic tool/logs can truncate the url so that the important MethodName is not shown.
  • urls redundant information which does not fit "modern" REST url schemes (at least the ".svc/binary")
• Application Insights (and maybe) other logging tools have problems with
  • truncating urls
  • the ".svc" makes request getting classified as "WCF" and makes Application Insights unconditionally grouping all "dependencies" by the service called

Proposed Solution

1. Manual service paths

A: Allow specifying paths at startup configration

var app = builder.Build();
app.MapOpenRiaServices("Services",  builder =>
{
	// MyDomainService becomes availible at "Services/My-CustomPath/MethodName" and "Services/MyDomainService/binary"
    builder.AddDomainService<MyDomainService>("My-CustomPath");
	builder.AddDomainService<MyDomainService>("MyDomainService/binary");
});

• This is simple to implement server side and (almost*) works with todays client as long as the user pass in a relevant Uri to the DomainContext
  • "almost*" : currently BinaryHttpDomainClient adds "/binary" to all urls, bit it should be possible to disable it

B; Allow specifying name via attributes

similar to now AspNetMvc allows name to be configured for [Route("Name")]

[EnableClientAccess("My-CustomPath)]
public class MyDomainService : DomainService
{ 

This approach means we should/can also

• Update codegeneration so that we take the path from EnableClientAccess instead of generating the path
• currently BinaryHttpDomainClient adds "/binary" to all urls, bit it should be possible to disable it

2. New Naming schemes

We add 2 new url naming options

• NameOnly - "TypeName/Method"
• FullName - "Some-Namespace-TypeName/Method"

With the following additional variants for backwards compatibility

• WCF (Legalcy) schem is availible with - "Some-Namespace-TypeName.svc/binary/Method"
• Default - (WCF + one of the new)

Configuration

1. Server side

Should we do a "builder" api?

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddOpenRiaServices(x => 
{
	x.WithUrlSceme(UrlScheme.FullName);
	
	// Do we want to enable more schemes ? 
	x.WithUrlSceme(UrlScheme.FullName | UrlScheme.WCF );
	x.WithUrlSceme(UrlScheme.FullName ,  UrlScheme.WCF );
});

2. And/or options

class HostingOptions??
{
    public UriScheme UriScheme { get; set: }
}

If so

• what is the name of the options class
• Do we bind it to appsettings by default?
  • "OpenRiaServices.Hosting" or "OpenRiaServices.Hosting.AspNetCore"
• Should we allow Configuration when calling "AddOpenRiaServices?"
  • as an Action<**Option> parameter or by a Configure[Options](Action<**> ) on a build class

3. Attribute based

Add an (assembly level) attribute that specify the endpoint scheme.

Attribute name should probably be something like: [Default]DomainService[Endpoint][Route][***]Attribute

• Default if it is only on the assembly level and never on class level
• Endpoint, Route or EndpointRoute to match AspNetCore names
• As suffix: Pattern, Scheme or Naming

Examples:
[assembly: DefaultDomainServiceEndpointPattern(EndpointPattern.Fullname)]
[assembly: DomainServiceEndpointPattern(EndpointPattern.Fullname)]
[assembly: DomainServiceEndpointScheme(EndpointScheme.Fullname)]
[assembly: DomainServiceEndpointRouteScheme(EndpointScheme.Fullname)]
[assembly: DomainServiceRoutePattern(DomainServiceRoutePattern.Fullname)]

Possible enum names

"Prefix:
- Endpoint*
- EndpointRoute*
- DomainServiceRoute(Routing)*
- DomainServiceEndpoint*
- DomainServiceEndpointRoute*

Suffixes:
- "" (None)
- Pattern
- Scheme
- Naming

Examples:
EndpointPattern.WCF
EndpointRoute.WCF
EndpointRoutePattern.WCF
EndpointRouteScheme.WCF
EndpointRouteNaming.WCF

Pros:

• The attribute can later on be allowed to be placed on class level (or add property to EnableClientAccess attribute)
• The same attribute can be used by both code generation and hosting (same pros as allowing name on EnableClientAccess)

Cons:

• Not very discoverable

Questions:

• Is it ok to only allow at assembly level to begin (yes)
• Should the attribute be taken from the "linked server project" and have it affect all domainservices in all projects, or should it be from same assembly as domainservice ?
  • start with only looking at "linked server project" ?, but what does it mean for "hosting" code and how do we know it?

Client Side

1. manual setting on BinaryHttpDomainClientFactory

• Should we add a setting similar to below ?
  it would have to "rewrite" any url passed into DomainContext constructor

DomainContext.DomainClientFactory = new BinaryHttpDomainClientFactory(...)
{
	// Property or constructor parameter ?
	// Needs to default to WCF if not specified so it works with old "WCF" backend
	UrlScheme = UrlScheme.FullName
}

2. Should we add a setting to the code generation =

If we add a msbuild parameter (or maybe assembly attribute in server project) we can change to code generation to emit the new kind of UrlScheme

• NOTE: The BinaryHttpDomainClient needs to stop adding "/binary" if the url does not contain ".svc"
  (We should probably make sure that "suffix" )

1. Manual service paths

Should we allow both A and B ?

[Daniel-Svensson]

For manual setting:

• Allow both, Look into enabling EnableClientAccess

The settings class will probably be called

1. OpenRiaServices.Hosting.AspNetCore. OpenRiaServicesHostingOptions
2. or OpenRiaServices.Hosting.AspNetCore. OpenRiaServicesOptions

UriShchem - really need a better name but unknown

• somehing with "Route" ?

[Daniel-Svensson]

fyi: I added a short section about having an assembly level attribute and try to have it affect both the server and client without any other public api changes