dekamik / dvbcrud Goto Github PK

• Investigate if we should implement If-Match header for PUT for mid-air collision avoidance.
• Investigate if we should implement If-None-Match header for GET and HEAD methods

DoD:

• Interface ICreatedAt exists and has property DateTimeOffset CreatedAt
• Interface IModifiedAt exists and has property DateTimeOffset ModifiedAt
• Abstract class DvbCrudDbContext exists
• DvbCrudDbContext.SaveChanges is overridden and updates CreatedAt and ModifiedAt if exists
• DvbCrudDbContext.SaveChangesAsync is overridden and updates CreatedAt and ModifiedAt if exists

DoD:

• Old DvBCrud repo is deleted
• DvBCrud.EFCore is renamed to DvBCrud

Think this through. We will definitely need a base response wrapper of some kind, maybe even ask consumers to define them.
We may also want to include/exclude fields like Id, CreatedAt and ModifiedAt automatically. At the same time - it's great if the models are as free as possible. Should look into this further.

Microsoft recommends using SQLite as in-memory DB in tests: https://learn.microsoft.com/en-us/ef/core/testing/testing-without-the-database#sqlite-in-memory

Read up on what is considered best practice when handling updates.
One way is to serve two methods:

• PUT: Updates entire objects with all property values
• PATCH: Updates only given property values on the object

DoD:

• We know how updates on REST APIs handled and performed, especially the semantics surrounding this
• If applicable: the tasks for implementing the new update methods are created and available.

The controllers should probably be unopinionated on Controller Route, while being opinionated on the endpoints themselves.
We also need to add types to the ProducesResponseType attributes.

OPTIONS should be added for endpoints, depending on allowed actions.

Check which other useful verbs should be added and create new issues for each.

A HEAD call to any endpoint must satisfy the following requirements:

• Must return status code 200 OK or 204 No Content, further investigation required
• Must contain header Content-Type - it may be hard-coded to application/json; charset=UTF-8. Double-check what is being returned by default on GET.
• Must contain header ETag - ID-specific HEAD calls should generate ETags by hashing the actual response, creating a strong validator. GET calls without IDs should use weak validators and hash the last modified timestamp. These must be prefixed with W/. An ETag could look like this: "33a64df551425fcc55e4d42a148795d9f25f89d4" or this: W/"0815".
• Must contain header Last-Modified - further development on Entity base class must be performed to support this.
• Must contain header Content-Length - this must return the size of resource content in bytes.

An OPTIONS call to any endpoint must satisfy the following requirements:

• Must return status code 200 OK or 204 No Content, further investigation required
• Must contain header Allow - it lists available methods for resource in a comma-seperated list like so: GET,POST,PUT,DELETE,OPTIONS.
• Must contain header Content-Type - it may be hard-coded to application/json; charset=UTF-8. Double-check what is being returned by default on GET.
• May contain header Content-Length - it may be hardcoded to 0.
• May contain CORS information, but not necessarily.

Investigate which of the 200 OK or 204 No Content status codes are the most appropriate when calling endpoints using HEAD or OPTIONS.

DoD:

• Readme is added for API and EFCore
• License is added for API and EFCore

DoD:

• All past tags and releases are deleted on Github
• All past packages has been deprecated on NuGet.org