terraform provider CRUD api insights

I am trying to create a terraform plugin and need to understand the life cycle of the resource.
For the life cycle we have the CRUD methods for a resource.
It would be really helpful to know when are these four called ?

// See Resource documentation.
type CreateContextFunc func(context.Context, *ResourceData, interface{}) diag.Diagnostics

// See Resource documentation.
type ReadContextFunc func(context.Context, *ResourceData, interface{}) diag.Diagnostics

// See Resource documentation.
type UpdateContextFunc func(context.Context, *ResourceData, interface{}) diag.Diagnostics

// See Resource documentation.
type DeleteContextFunc func(context.Context, *ResourceData, interface{}) diag.Diagnostics

yes I went through this.
My understanding after reading is below:

1. The Read of the CRUD will be called at the plan phase.
   On that basis it will be decided, it it is a create or update.

2. The create and update will be done on apply phase. 

3. The delete will be called on destroy phase. 

Then I tried out the example provided by keeping the read function empty and I can see that the create, update and deletion of resources works like charm even with the Read functionality also. So the use of Read function is still a mystery.

PS: While reading the documentation I can see that the SetId() and ID() seems important, but I am still not able to understand the use of them.

One way to think about this is to understand Terraform's resource instance change lifecycle (written from the perspective of the underlying provider protocol) and then consider how each of those protocol-level calls corresponds with Terraform SDKv2 features.

Here's a summary of how they relate:

• ValidateResourceConfig doesn't have a direct analogy in the SDK, but it does cause your various individual ValidateFunc functions to run, on a per-attribute basis.
• PlanResourceChange corresponds to CustomizeDiff in the SDK.
• ApplyResourceChange corresponds to different functions in the SDK depending on which action was planned:
  • If the planned action is "will be created", SDK calls Create.
  • If the planned action is "will be updated in place", SDK calls Update.
  • If the planned action is "will be destroyed", SDK calls Delete.
  • If the planned action is "must be replaced" then that's really a shorthand for either a create followed by a delete or the other way around, so there will be two separate calls to ApplyResourceChange handling each of those simpler actions separately.
• UpgradeResourceState corresponds to the state migration mechanisms.
• ReadResource corresponds to Read in the SDK.
• ImportResourceState corresponds to Importer.

These analogies are not direct because SDKv2 intentionally raises the abstraction above the low-level protocol that Terraform Core understands, but it will hopefully still at least help you see at which points in the process these functions will run and how the results of one will feed into others downstream.

SDKv2 has various behaviors of its own which it performs automatically before or after calling into the functions you defined in your provider, so the way your provider code experiences these operations will tend to be a little different than what the raw protocol requires, but the SDK is aiming to help you correctly implement the details written in that "resource instance change lifecycle" document.