@ReadOnly

 
  @ReadOnly
 

•  Because of Limitations like 'Maximum no.of items in a collection that can be iterated is 1000' or 'generally query in VF should not go beyong 50,000 rows'.  It was not possible to show millions of records on VF page.                                                                                                     But thanks to @ReadOnly annotation in API version 23.0 now we can !
• Only available for Web services and the Schedulable interface.
• Used for methods.
• Allows you to perform unrestricted queries against the Force.com database.  All other limits still apply.
• To use the @ReadOnly annotation, the top level request must be in the schedule execution or the Web service invocation. 

   For example, if a Visualforce page calls a Web service that contains the @ReadOnly annotation, the request fails because Visualforce is the top level request, not the Web service.

• ReadOnly mode restricts you from DML Operations, calls to System.Schedule, Sending an emails, calls to @Future annoted methods.
• @ ReadOnly methods should also have @Remote action annotation and either global/public or static access specifiers.
• Visualforce controller methods with the @ReadOnly annotation automatically take advantage of read-only mode and help us to retrieve a larger collection of records.
• Very helpful and handy in a visualforce controller for building super custom reports.

  More : 
  https://success.salesforce.com/ideaView?id=08730000000kourAAA

Difference between 15 digit and 18 digit ID in Salesforce

• 15 digit case-sensitive version 
• 15 digit ID is referenced in the UI
• 18 digit case-insensitive 
• 18 digit id is referenced through in the API
• Why do we need 18 digit IDs, because many Legacy system [ex: excel sheets] work with Case insensitive IDs
• The id displayed by a report is the 15-digit case-sensitive id. The ids returned by web services api are 18-digit id. For updates web service accept both the 15-digit and 18-digit ids.

BreakDown of 15 Characters - 

As there is a combination of lower and upper case letters the casing of the 15 character Id has significance. E.g. 50130000000014c is a different ID from 50130000000014C.

Within a 15 character Id the breakdown is:

• First 3 characters - The first 3 characters are the key prefix that identify the object type. There are some exceptions to this where multiple objects all share the same key prefix! 
• There are a number of fixed key prefixes that are common across all of Salesforce .  Custom objects in managed packages can have a different keyprefix in each installed org.(Cross check once)
• The 4th and 5th characters - Reserved. Currently used for the instance id / POD Identifier. Indicates which pod/instance the record was created on.
• 6th character - Reserved. Will be 0 until such time that Salesforce has a need for it. See more
• Remaining 9 characters - basically a really big number. Like 62^9 big.

To this you can add an optional 3 character suffix that will make the Id unique case-insensitive.

 This is useful when working with programs that can't maintain the case of the ID (E.g. Excel VLookup).

See More 1 

SOAP API and REST API

* SOAP API and REST API are two commonly used API's to expose your data from force.com platform to the other platforms(JAVA , .NET ,etc) or to allow external application to invoke Apex methods.

What is SOAP ?

The Simple Object Access Protocol (SOAP) is an attempt to define a standard for creating web service APIs. It is a pattern, a web service architecture, which specifies the basic rules to be considered while designing web service platforms. It typically uses HTTP as a layer 7 protocol, although this is not mandatory. The SOAP message itself consists of an envelope, inside of which are the SOAP headers and body, the actual information we want to send. It is based on the standard XML format, designed especially to transport and store structured data. SOAP may also refer to the format of the XML that the envelope uses.

SOAP is a mature standard and is heavily used in many systems, but it does not use many of the functionality build in HTTP. While some consider it slow, it provides a heavy set of functionality which is a necessity in many cases. It might now be the best solution for browser-based clients, due to its custom format.

 What is REST ?

The Representational State Transfer (REST) is another architectural pattern (resource-oriented), an alternative to SOAP. Unlike SOAP, RESTful applications use the HTTP build-in headers (with a variety of media-types) to carry meta information and use the GET, POST, PUT and DELETE verbs to perform CRUD operations. REST is resource-oriented and uses clean URLs (or RESTful URLs).

For example :

http://www.developingthefuture.com/index.php?page=foo

becomes

http://www.developingthefuture.com/foo

This kind of URLs syntax greatly improves both visibility and usability. It doesn’t use any query strings, and it also provides certain SEO benefits (the crawlers just love plain text). The body of the REST message can be XML, JSON or any other format, although JSON is usually the preferred choice. On the other hand, you can’t use JSON with SOAP. Or at least not entirely, because SOAP uses XML by definition for it’s envelope. It should also mentioned that REST is, by design, protocol-agnostic, although it is usually used with HTTP. 

SOAP API

1)Supports data in the form of XML only 2)Requires WSDL for the integration 3)Use SOAP API in any language that supports Web services.

REST API

1)Supports both XML and JSON format 2)Preferred for mobile and web apps since JSON being Lighter the app runs smoother and faster

>>>>>>> VISIT THIS FOR MORE INFORMATION  >>>>>>>>>>

(Courtesy Groundwire Consulting)

Difference between Object-Level Security , Field-Level Security and Record-level Security

Object-Level Security

The bluntest way that we can control data is by preventing a user from seeing, creating, editing, and/or deleting any instance of a particular type of object, like a position or review. Object-level access allows us to hide whole tabs and objects from particular users, so that they don't even know that type of data exists. On the platform, we set object-level access rules with object permissions

on user profiles.

Field-Level Security

A variation on object-level access is field-level access, in which a user can be prevented from seeing, editing, and/or deleting the value for a particular field on an object. Field-level access allows us to hide sensitive information like the maximum salary for a position or a candidate's social security

number without having to hide the whole object. On the platform, we set field-level access rules with the field-level security.

For More Detail Click Field-Level Security

Record-Level Security

To control data with a little more finesse, we can allow particular users to view an object, but then restrict the individual object records that they're allowed to see. For example, record-level access allows an interviewer like Melissa Lee to see and edit her own reviews, without exposing the reviews

of everyone else on her team. On the platform, we actually have four ways of setting record-level access

rules:

• Organization-wide defaults allow us to specify the baseline level of access that a user has in your organization. For example, we can make it so that any user can see any record of a particular object to which their user profile gives them access, but so that they'll need extra

permissions to actually edit one.

• Role hierarchies allow us to make sure that a manager will always have access to the same records as his or her subordinates.

• Sharing rules allow us to make automatic exceptions to organization-wide defaults for particular groups of users.

• Manual sharing allows record owners to give read and edit permissions to folks who might not have access to the record any other way.