Api Design:

For best practices in REST Api design i can recommend following article from microsoft: https://docs.microsoft.com/en-us/azure/architecture/best-practices/api-design

I want to describe some implementation details in this repository. In general, this API is built to use in internal projects, for example to provide functionality for an angular/react client.
For public API's i would add features like HATEOAS and Versioning, as mentioned in the microsoft documentation.

Models

I'm using separate models for Get/Put/Post requests.
GET request: return model with all information (including id)
POST request: take model with all properties needed to create the new resource and optional properties (nullable)
PUT request: take model with all properties that can be updated (properties should be optional/nullable)

Paging / Filter / Sorting

Shown on endpoint: /api/Bill/query
To enable paging, filter and sorting, http route parameters can be added to the request. On each request 1 filter and 1 sort parameter an be set. The properties, which are available for sorting and filtering are defined in an enum in the model class (BillModel). The functionality, to apply paging/filter/sorting directly to the EF Core query is implemented in Core/QueryParameter.
This kind of query parameters (specially filter/sorting) are more generic and can be used for each model.
If some special functionality is used, an own QueryParameter class can be created, which is shown as example on endpoint: /api/Bill [List]

Problem Details:

To return details on an error status code, the Problem details object is used (according to RFC 7807).
As in an ASP.NET Core project, an error object can only be returned for "BadRequest" and "NotFound" ActionResults, i'm using the "Hellang.Middleware.ProblemDetails" nuget package, which enables to return problem details also for error codes 401/403/...
This package allows it, to map Exceptions to Status Codes.
In the Domain project, i have declared following Exceptions:

• BadRequestException (400)
• NotFoundException (404)
• ConflictException (409)

These Exceptions are mapped to the corresponding Status Code (reference in code: CleanArchitecture.Web.Extensions).
If any of these Exceptions is thrown in the application code, automatically the corresponding problem details object is returned in the response message. In development mode, or if set as environment variable, the stack trace in case of an error is added to the problem details object.