[DRAFT] Version 2.0 Design Specifications

Restier Version 2.0

Purpose

To build a modern, streamlined framework for implementing secure, scalable, and queryable APIs.

This framework will:

• Leverage the power and familiarity of OData maintain compatibility with existing .NET API Deployments.
• Turn Restier into a SimpleMessageBus-like pipeline for processing incoming and outgoing entities over HTTP.
• Run natively on .NET 8.0 and later.

Two Pillars

• Magic API
• Data Processing Pipeline

Goals

• Use any ASP.NET API Stack (Controllers, Middleware, Minimal APIs)
• Use any Query layer (OData URLs, GraphQL, etc)
• Use any Persistence Stack (EF6, EFCore, Dapr, NoSQL)
• Use any Output Stack (OData, GraphQL, gRPC)
• Address end-to end serialization issues (update / remove the OData Serializer?)

Possible Goals

• Let you operate over dynamic databases?

Non-Goals

• Restier on Java / Python / Go
• Querying over Twitter / Azure AD / OpenAI

Issues To Address

• Authorization only handles access to EntitySets by default. The user needs to be able to define rules that control access to individual Entities.

• Nesting handlers is a sub-optimal way to handle processing pipelines. Process should pull multiple handlers conforming to the same interface from the DI container and execute them in the order they were registered.

• There are levels of the pipeline that are more complicated than they need to be.

• Consider changing the name of "Bound" functions to "Attached" functions. Functions can be attached to specific EntitySets or Entities, or they can reside on the root of the service.

  • Pros:
    • Separates the concept of where functions live from front-end programming concepts like "data-binding".
  • Cons:
    • People may be used to the existing concept.

• Consider having separate attributes for "root" Operations vs Attached Operations.

  • Pros:
    • More predictability on which properties need to be populated to meet end user expectations.
    • Fewer permutations on property assignment that lead to failure.
  • Cons:
    • Increases internal complexity looking for multiple attributes
    • Breaks people's code.

Dependency Injection

Restier was designed at a time when there were about 13 different DI solutions on the market. Now, DI is a fundamental .NET concept that permeates many systems. Restier's use of DI needs to be overhauled so it is a good citizen to apps it is installed in.

Issues To Address

• ApiBase-derived classes have to use service location instead of constructor or method injection to resolve dependencies.
• Because the class inheriting from ApiBase is not itself a controller, it does not have direct access to the HttpContext for the request. You can inject the IHttpContextAccessor into the constructor for your Api class, but the issue above makes it clunky.
• Hopefully resolve this issue about DI container hierarchies for OData 8.0.
• Implement Container hierarchies in Restier
• Simplify services that don't require state so that as many as possible can be application-wide services.

Reflection

Issues To Address

• Determine if caching Convention-Based lookups would improve performance.