jessicamorris
commented
7 years ago My life would be much easier with POST, since I won't have to deal with parsing XML/JSON coming back in a GET request (libcurl does more work for me for POSTs). Richard has told me you guys already verbally agreed on POST, just throwing in my two cents :)
Looking into how this will work, I think there is too much information in the query string, so I would rather see the Auth information in the body of the request. However, it seems like you aren't supposed to have bodies for GET requests (though we can break this rule if we really want). Then the problem is that a POST for this isn't really correct either, since it isn't modifying state or anything on the server side.
One solution I stumbled on discusses a dynamic resource approach, where the POST will send the info, then return a URL to GET from which will give the response. With this approach we could also get information from different sources (phone, lock system, web client?), and aggregate the requests to be part of a session, but I think this might be getting a bit complicated for our system.
Other solution would be to defy the convention a little bit and just have the GET or POST do what we discussed, where the response back to the lock system is either the key to unlock the lock, or something else to stay locked.
I am thinking to go with the second one, at least to start and get something working sooner that is simple.