RDAP corrige les principales faiblesses du WHOIS. Les réponses sont du JSON aux noms de champs définis ; un logiciel peut donc les lire sans deviner. Les requêtes passent en HTTPS, les valeurs de statut et les dates d'événements sont normalisées, les erreurs utilisent les codes de statut HTTP (un 404 signifie qu'un tel objet n'existe pas), et les serveurs peuvent offrir différents niveaux de détail aux utilisateurs authentifiés.
Les clients trouvent le bon serveur grâce aux fichiers d'amorçage (bootstrap) que publie l'IANA : l'un liste l'URL de base RDAP de chaque TLD, d'autres font de même pour les plages d'adresses IP et les numéros d'AS. Un client télécharge le fichier, y cherche le TLD et envoie une requête du type /domain/example.com au serveur indiqué. La réponse du registre renvoie souvent vers le serveur RDAP du bureau d'enregistrement pour des données complémentaires.
Tous les registres et bureaux d'enregistrement de gTLD doivent fournir RDAP. Les registres nationaux décident par eux-mêmes ; un certain nombre de ccTLD sont donc absents du fichier d'amorçage et ne peuvent être interrogés que par le WHOIS classique. Comme pour le WHOIS, les coordonnées personnelles sont généralement masquées dans les réponses publiques.
Exemple
GET https://rdap.registry.example/domain/example.com
{ "objectClassName": "domain", "ldhName": "example.com",
"status": ["client transfer prohibited"],
"events": [{ "eventAction": "registration", "eventDate": "1995-08-14T04:00:00Z" }] }