A fantastic explanation of REST apis.
http://tomayko.com/writings/rest-to-my-wife
More info: http://stackoverflow.com/questions/671118/what-exactly-is-restful-programming
Also really nice and simple explanation to do Restful APIs in below blog:
“Teach your dog to REST”
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.
MyISAM was the default storage engine chosen by MySQL database, when creating a new table. But since 5.5 version, InnoDB is the default storage engine.
The major differences between these two storage engines are :
Tables created in MyISAM are known to have higher speed compared to tables in InnoDB. But since InnoDB supports volume, transactions, integrity it’s always a better option which you are dealing with a larger database. It is worth mentioning that a single database can have tables of different storage engines.
MyISAM is good for read-heavy applications, but it doesn’t scale very well when there are a lot of writes. Even if you are updating one field of one row, the whole table gets locked, and no other process can even read from it until that query is finished. MyISAM is very fast at calculating SELECT COUNT(*) types of queries.
InnoDB tends to be a more complicated storage engine and can be slower than MyISAM for most small applications. But it supports row-based locking, which scales better. It also supports some more advanced features such as transactions.
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
isset — Determine if a variable is set and is not NULL
empty — Determine whether a variable is empty. it will return true if the variable is an empty string, false, array(), NULL, “0″, 0, and an unset variable. (equivalent to !$var without the notice). empty() comes with quite a few caveats, since it considers the integer 0 and the string “0” to be empty (among other things).
is_null — Finds whether a variable is NULL
is_null() is opposite of isset(), except for one difference that isset() can be applied to unknown variables, but is_null() only to declared variables
array_key_exists vs isset
isset() does not return TRUE for array keys that correspond to a NULL value, while array_key_exists() does.
$presidents = array(1 => “washington”, “adams”, “jefferson”);
function checkSubmit(e)
{
if(e && e.keyCode == 13)
{
document.forms[0].submit();
}
}
Then add the event to whatever scope you need eg on the div tag
<div onKeyPress="return checkSubmit(event)"/>
http://stackoverflow.com/questions/29943/how-to-submit-a-form-when-the-return-key-is-pressed