Your understanding of the REST methods is close to correct, but not exactly right. Specifically, your description of PUT is not accurate: PUT is used to either create a new resource or to edit an existing one. The difference between POST and PUT is less about creating vs. updating, and more about whether the URL for the resource is known in advance by the client or not. It is certainly a common pattern for POST to be used for resource creation, because typically URL's for new resource contain server-generated ID's, but using PUT to create a resource is certainly still valid for many use cases.
All that being said, this correction to your REST understanding doesn't solve the problem you are trying to address. You can design your service using a REST approach or using SOAP. Neither will automatically handle your security concerns, but your security concerns can be solved with either approach.
Assuming you want to stick with the REST approach (it's simpler in most cases, so I would), then your real question should be about how to design your REST interface to address security concerns. Encryption is probably a good solution, but the specifics of how to encrypt will depend a lot on how the service will be deployed and how securely encryption keys could be shared. The key point is that you will need to design with appropriate security considerations no matter which design approach you use.
manpreet![Tuteehub forum best answer]()
Best Answer
2 years ago
I currently am in charge of designing a service that will check for my company softwares's copyright. Typically, this service will check serial number whenever user install or use the applications. At first, I thought of using REST, but base on my knowledge, the purpose of REST's web methods as following:
Thereby in my case, in order to not violate REST's rule, I must use GET to send serial number to server. But this will lead to potential security risk which I want to avoid.
Then I thought of SOAP. But SOAP using XML format verbose so that will slower and less scalability than using REST (please correct me if I was wrong.)
So I need an advice in which service technology should I use to implement a lightweight, scalable but still preserve performance.