put, post can be used for creating, but put is idempotent and client specify the resource url that is created (unlike post where the server decides on created url, client posts to a general url):

PUT /questions/<new_question>  (returns only 201, and also just to follow convension of HTTP creation, return URI for the new resource returned in the Location header, optionally could also return the created resource to save another round trip to client)

POST /questions (create a new one, send back to client the created resource url, 201 and location header to the created resource )

post could also modify -

POST /questions/<existing_question>  (modify, but send the *entire* resource in the post body. Sends back to client the entire resource. )

(If an existing resource is modified, either the 200 (OK) or 204 (No Content) response codes SHOULD be sent to indicate successful completion of the request).

for *partial* modification use patch and send to server only what to modify:

PATCH questions/<existing_question> 

or

PATCH /users/1

{"email": "user1@mydomain.com"}

it sends back in response to client the entire (modified) resource, and 200 http code.

A PUT, POST or PATCH call may make modifications to fields of the underlying resource that weren't part of the provided parameters (for example: created_at or updated_at timestamps). To prevent an API consumer from having to hit the API again for an updated representation, have the API return the updated (or created) representation as part of the response.

In case of a POST that resulted in a creation, use a HTTP 201 status code and include a Location header that points to the URL of the new resource.

But I see some people also return the Location as response to PUT, probably just to follow convention of HTTP that creation.