For Bluetooth Low Energy, henceforth abbreviated to BLE, perhaps the most important thing is recognizing device roles in your particular application.
There are 2 roles to be assumed:
A GATT Client
A GATT Server
The GATT Client is largely the brains behind the operation. The Client picks up on Servers that are advertising nearby and initiates the connection between the two. This connection may or may not be encrypted; it is largely dependent on the Client's request, and to a lesser extent the implementation of the BLE API on the servers end. A single Client may be connected to multiple Servers and still pick up advertisement packets from nearby Servers.
The GATT Server as the name implies, exists to respond to requests of the Client. Upon successful connection after advertising, the Server provides the GATT profiles it supports to the Client and waits for the next request from Client. A Server can only be bound to one Client, and once connected / bound, it cannot advertise its presence again unless disconnected.
At this point, I will segue into the term introduced above: A GATT Profile, and some of the nuances around it and it's children: GATT Services and GATT Characteristics.
GATT PROFILES
To lift from the official Bluetooth developer page:
The GATT Profile specifies the structure in which profile data is exchanged. This structure defines basic elements such as services and characteristics, used in a profile. The top level of the hierarchy is a profile. A profile is composed of one or more services necessary to fulfill a use case. A service is composed of characteristics or references to other services. Each characteristic contains a value and may contain optional information about the value. The service and characteristic and the components of the characteristic (i.e., value and descriptors) contain the profile data and are all stored in attributes on the server.
In other words, if BLE were a sandwich, the GATT profile would be the bread, enclosing the lettuce and meat underneath: The GATT services and GATT characteristics. GATT profiles are identified with universally unique identifiers (UUIDs) which are a character String of hexadecimal units. The Bluetooth specification by default provides certain profiles for common scenarios, a list of them can be found here: Bluetooth GATT profiles
These GATT profiles all have UUIDs that are 16 bits in length. Should your particular application not have an applicable profile, you can define your own with its own UUID. Your custom UUID has to 128 bits long however, and you can create some for free here: Custom UUID Generator.
GATT SERVICES
Again, to quote someone much more eloquent, Adafruit describes GATT Services as:
Services are used to break data up into logic entities, and contain specific chunks of data called characteristics. A service can have one or more characteristics, and each service distinguishes itself from other services by means of a unique numeric ID called a UUID, which can be either 16-bit (for officially adopted BLE Services) or 128-bit (for custom services).
They are identical to Profiles in the way UUIDs are assigned. When using a GATT service, it is not necessary to utilize all the GATT characteristics it provides. Adafruit mentions the Heart Rate Service which has 3 characteristic, of which only the Heart Rate Measurement is mandatory. Both the Body Sensor Location and Heart Rate Control Point are optional.
GATT CHARACTERISTICS
Borrowing yet again from Adafruit:
The lowest level concept in GATT transactions is the Characteristic, which encapsulates a single data point (though it may contain an array of related data, such as X/Y/Z values from a 3-axis accelerometer, etc.).
Similarly to Services, each Characteristic distinguishes itself via a pre-defined 16-bit or 128-bit UUID, and you're free to use the standard characteristics defined by the Bluetooth SIG (which ensures interoperability across and BLE-enabled HW/SW) or define your own custom characteristics which only your peripheral and SW understands.
As an example, the Heart Rate Measurement characteristic is mandatory for the Heart Rate Service, and uses a UUID of 0x2A37. It starts with a single 8-bit value describing the HRM data format (whether the data is UINT8 or UINT16, etc.), and the goes on to include the heart rate measurement data that matches this config byte.
Characteristics are the main point that you will interact with your BLE peripheral, so it's important to understand the concept. They are also used to send data back to the BLE peripheral, since you are also able to write to characteristic. You could implement a simple UART-type interface with a custom 'UART Service' and two characteristics, one for the TX channel and one for the RX channel, where one characteristic might be configured as read only and the other would have write privileges.
So there it is. A simple and mostly outsourced introduction to BLE. GATT Clients request data form GATT Servers who organize the data in a nested form consisting of GATT profiles, services and characteristics.
In an attempt to be original, and to build upon the sandwich analogy presented above, consider yourself to be at restaurant where you order sandwich. Your waiter has to wait for you to order, and what you want is what he provides. You ask for a certain sandwich, the bread is wheat, the meats are beef and bacon. You want your beef medium rare and your bacon fried to a lovely crisp. In BLE terms:
You - GATT Client
Waiter - GATT Server
Bread - GATT Profile
Meats - GATT Services
Meat cooking options - GATT Characteristics
Voila! You have successfully built a rather delicious BLE dinner.