Before I began developing a RESTful API I used a query similar to this:$query = INSERT INTO availability (user_id, date, status)  .         VALUES ('.$id.', '.$date.', '.$status.')  .         ON DUPLICATE KEY  .         UPDATE status='.$status.';Yes, I know it's subject to SQL injection. Anyway, I'm having trouble deciding if this should be a POST or PUT request since it can insert or update. I got to thinking: maybe it's better to have both POST and PUT methods in the API and then the client determines which one to call.Is this usually how RESTful APIs handle this scenario?
Client or server check if insert or update in RESTful architecture
php;rest;mysql
I got to thinking: maybe it's better to have both POST and PUT methods in the API and then the client determines which one to call.Is this usually how RESTful APIs handle this scenario?Not really.  Think about how you would implement this in a web site.  Somebody would go to the home page, and then follow a link to a form allowing them to provide the data they would want to use, and then they would submit the form, and get a message back announcing whether the submission was successful.The representation of the form would describe the identifier for the resource to submit the request to, and the method to use (in an HTML form, that would always be a POST, of course).So you could use POST, or PUT, or alternate back and forth, or do whatever you like by simply altering the representation of the form.From a REST perspective, the only important thing is that you respect the uniform interface; which in this case means that the semantics of your messages are aligned with the HTTP specification.REST really doesn't care which method you use, so long as (a) you use it correctly according to the uniform interface, and (b) the client discovers which method to use by consuming the hypermedia provided by the server.Semantically, a PUT is supposed to be a complete replacement.  RFC 7231 is the relevant standard.The PUT method requests that the state of the target resource be created or replaced with the state defined by the representation enclosed in the request message payloadIt's a little bit weird that you insert $date but you don't update it.  Not wrong -- but tough to tell from the example whether date is part of the representation enclosed in the request message payload.  The semantics of PUT allow clients and intermediaries to make certain assumptions about the state of the updated resource without sending a GET to the server -- it's the responsibility of the server to ensure that those assumptions hold.