How to design API resource which doesn't map to CRUD operations and has multiple business scenarios

[#1]

I recently came across a few use-case which we're planning to expose as REST api's for internal application consumption. Had few items that I wanted to discuss with broader community here before I proceed with design

1.) How to design the path and leverage appropriate Verb for a resource which doesn't really map to CRUD operations ? E.q. Look at following functionalities.

a.) Calculate initial premium for Auto quote based on customer's information

b.) Calculate premium based on coverage's customized by prospect.

c.) Login/Logout functionality

d.) Refresh access token

Here's what I was thinking in terms of design. Please share your thoughts on this.

Calculate initial auto premium

/insurance (base path)

/auto/premium (resource path)

POST (verb, posting customer details to get the premium)

Calculate custom premium

I was planning to leverage same resource (as mentioned above) considering that both gonna return the premium. But since request will differ to get the custom premium, should we create a new resource here or leverage the same ? What are the best practices? Looking forward to an expert opinion here. @Dino

/insurance (base path)

/auto/premium (resource path)

POST (verb, posting customer details along with customized coverages to get the premium)

Login/Logout functionality

/user (base path)

/session (resource path)

POST (verb, will create the user session means login)

DELETE (verb. will delete the user session means log out)

Refresh Access Token

/user (base path)

/session (resource path)

PUT (verb, send request to update the access token)

[Former Community Member]

for "a", I would consider quote instead of premium. A quote is a resource that can have CRUD operations. Quotes have quoteIds. Various scenarios can be presented.

For "c" and "d", I'd stick with the oauth spec.

[#3]

Thanks @Srinandan Sridhar for the response.

We're already using the quote resource to create(POST) quote Id, update/save (PUT) quote in database at various stages. Premium calculation requires lot of details in request such as Vehicle, driver etc. so though theoretically premium is a part of an overall quote but technically, we're visualizing this as a separate resource/operation.