http://crackstation.net/hashing-security.htm
Salting inherently makes your user’s passwords better automatically by prepending or appending a random string. So lookup tables become useless.
But if the password hash and salt table is compromised then salt will not help (as in LinkedIn case). LinkedIn should have been using bcrypt, which is an adaptive hash that would have slowed the brute force time down to the order of 10s of hashes per second.
Both cookies and sessions are available to you as a PHP developer, and both accomplish much the same task of storing data across pages on your site. However, there are differences between the two that will make each favourable in their own circumstance.
Cookies can be set to a long lifespan, which means that data stored in a cookie can be stored for months if not years. Cookies, having their data stored on the client, work smoothly when you have a cluster of web servers, whereas sessions are stored on the server, meaning in one of your web servers handles the first request, the other web servers in your cluster will not have the stored information.
Sessions are stored on the server, which means clients do not have access to the information you store about them – this is particularly important if you store shopping baskets or other information you do not want you visitors to be able to edit by hand by hacking their cookies. Session data, being stored on your server, does not need to be transmitted with each page; clients just need to send an ID and the data is loaded from the local file. Finally, sessions can be any size you want because they are held on your server, whereas many web browsers have a limit on how big cookies can be to stop rogue web sites chewing up gigabytes of data with meaningless cookie information.
So, as you can see, each have their own advantages, but at the end of the day it usually comes down one choice: do you want your data to work when you visitor comes back the next day? If so, then your only choice is cookies – if you have any particularly sensitive information, your best bet is to store it in a database, then use the cookie to store an ID number to reference the data. If you do not need semi-permanent data, then sessions are generally preferred, as they are a little easier to use, do not require their data to be sent in entirety with each page, and are also cleaned up as soon as your visitor closes their web browser.
http://spf13.com/post/soap-vs-rest
SOAP:
– Transport Independant (REST requires HTTP. SOAP can work on HTTP, SMTP, etc)
– Built in Error Handling
– Only XML
– Provides good ACID Transactions.
– Exposes pieces of application logic , Exposes operations
– Enterprise level security since it supports WS-Security
– Suitable for banking applications
REST
– Easier Learning Curve
– Efficient and Fast : Smaller message format
– Can use XML, JSON, etc
– REST gives access to named resources