New answers tagged


It all depends on what the GET in the api is doing but I think it is restful to have a multipart PUT. The type of the payload doesn't change semantics of what a PUT is in REST. For example if I had an Amazon S3 like REST api it would be restful to update the file content if a multipart PUT was made on a resource.


If you GET the same resource at the same URI, what do you expect to get back? Do you expect to get the same multipart content that you sent, i.e. the data and the file, or just one of them? If it's the latter, then it's not a RESTful use of PUT, since one URI no longer refers to one resource. You would be better off considering using POST, or splitting the ...


I would use one of our successful projects as example. Sentilo Sentilo is (in bottom lines) a data concentrator that stores milion of entries from any sort of sensor, gadtget or client. It store data into noSql db and the way to do this is by Restful and stateless webservices. Which accepts json as data representation. Then offers also webservices to serve ...


This answer will fall into the category of "suggest a better strategy". Gathering stats on infrastructure assets (not just servers) is what I am currently doing for a living in a global financial services leader. I am trying to understand why one would avoid using a database to hold the bits that are gathered. If cost is a concern there are open source ...


A thing to consider also is caching. Your backend could see several calls to same URL, with same GET/POST parameters but a different header access token and consider content can be cached and severs to any body.


I think 409 is a good choice there if the conflicted state was achieved by another client sending in a PUT i.e. A does a GET B does a GET B does a PUT state is now different A tries to do a PUT but the new state is not possible so A gets a 409. This only works if the server can determine the bad state transition, either from FSM transitions that are ...

Top 50 recent answers are included