My understanding of REST is that a resource endpoint should expose the same schema, irrespective of the HTTP VERB. E.g. the same JSON schema is used for:
PUT /foo/
GET /foo/{id}
POST /foo/{id}
How do I handle fields that should only be populated by the server. E.g. created_on, created_by, id.
Should I use separate schema per endpoint?
Do nothing and ignore the created_on value if it's sent by the client?
Return an error if the client tries to send created_on?
My understanding of REST is that a resource endpoint should expose the same schema, irrespective of the HTTP VERB.
That's not quite right. We would normally expect GET and PUT to use similar representations. POST can use the same representations, but frequently doesn't.
For example: on the web we GET HTML documents, but we POST key/value pairs (application/x-www-form-urlencoded).
How do I handle fields that should only be populated by the server. E.g. created_on, created_by, id.
Treat them as optional fields in your schema is the common answer, I think.
Also, keep in mind that the server is not constrained by the semantics of the request. PUT means "make the resource look like the body of the request", but it is perfectly reasonable for the server to make changes of its own to the resource.
Do nothing and ignore the created_on value if it's sent by the client?
Just so.
You need to be a little bit careful not to imply that you've accepted the provided representation as is, see RFC 7231.