I have a need for persistence of client state and am wondering what the problems would be with this approach.
I want to provide a URL to a client that uses HTTPS and basic authentication, they would just PUT and GET a Blob of text containing JSON. On the server side, I can parse it when PUTting to see if it's semantically correct before storing it.
What are the gotchas with this?
Are you sure you want to use PUT as opposed to POST? Generally, PUT is used for updating data, POST for adding new data.
One gotcha with GET is that data can be cached at the client.
Other than that - I don't see any gotchas.
Yes, PUT can be used for create as well. The difference is that with POST you are typically sending your data to the URI of a collection and the server determines the URI of the finally created resource (returned to you in a 'location' header of the '201 created' response).
However, if the client has control over the URI of the resource then you may as well use PUT, directly to the desired resource URI, not to the URI of the collection.
Another way to think about it is that by convention, PUT has to be idempotent, while POST does not. This means that it doesn't make a difference whether the PUT request is sent once or more often. The result is the same: The first time the new entity is created, any additional PUT just updates the entity, but with the same data, so nothing really changes.
However, if you resend the POST request (to the collection URI) then you would actually create multiple - albeit identical - entries in the collection. That's also why your web browser asks you if you want to resubmit a form (usually a POST), since submitting it once is very different than submitting it multiple times.