restful url - REST API Design - Create Resource By Loading By ID -

my rest service needs support ability load/reload resource vs. outright create it.

api far:

get /books /books/12345 delete /books/12345 

a book looks like:

{"id": 12345, "title": "three little bears", "author": ...} 

it's unclear whether

request:  put /books/12345 response: http 204 no content 

or

request:  post /books payload:  {"id": 12345} response: http 201 created, location: /books/12345 

is better approach "load"/"reload" book.

details: "load"/"reload" consult database retrieve book id, , place result in persistent cache. cache consulted requests. book's attributes can change in database, meaning "load"/"reload" isn't idempotent. admin able use load/reload , delete operations.

i believe correct approach post, because put supposed idempotent. however, post seems odd because multiple posts against /book id=12345 result in single resource being created (albeit re-created multiple times)

i've considered additional options below, seem more egregious:

* post /books/12345/load * post /books/load, payload {"id": 12345} * post /load/book, payload {"id": 12345} 

thoughts?

to complicate matters further, i'd offer asynchronous load/reload operation, don't want create operation/job resource user can track, want fire-and-forget.

example: book 12345, load/reload asynchronously cache. need service respond http 202 accepted , that's sufficient. no need ever ask progress of load/reload.

tl;dr: i'm building rest service front cache of books. load/reload , delete operations can executed admin, whereas open all. load/reload operation should load/reload record database.

if correct, have a

• origin
• database
• clients

if client gets book, fetches resource database. database doesn't know if book altered in meantime, serves outdated version? therefore want client post or put resource force database fetch entry again origin?

think this:

the origin caches content, database caches content , client caches too.

if user hit f5 client reload resource, right? behaviour? no. better client check wether resource outdated or not , fetch if neccessary? yes. achieved sending http-head asking server date of last modification, if clients retrieval-date older needs fetch again, otherwise can serve cache.

same apply databse/origin-constellation. database needs validate content still latest request , serve or fetch origin, update caches , serve new entry.

so client still get resoure, accurate if doesn't want alter resource in way.