Einer der Vorteile von fachspezifischen REST-APIs ist die besser Darstellung von Beziehungen innerhalb der Daten. In dem obigen Beispiel ist dieses gut an den Adressen erkennbar. Außerdem können Daten aus verschiedenen Quellen gemischt werden. Diese Quellen können Notes-Dokumente, ERP-System und relationale Datenbanksystem sein. Nach Außen ist die Herkunft der Daten nicht erkennbar.
Der wichtigste Vorteil ist aber Flexibilität: Mit der Veröffentlichung der REST-API wird eine Art Vertrag eingegangen. Die Nutzer der REST-API erwarten, dass die Schnittstelle stabil bleibt. Bei datenzentrierten REST-APIs gibt es keine Möglichkeit die interne Struktur der Daten zu ändern, weil jede Anpassung zu einer Änderung der Schnittstelle und somit zum "Vertragsbruch" führen würde. Selbst wenn den Entwicklern des Backends eine geniale Methode zur Performance-Verbesserung einfallen würde, könnten sie die Methode nicht einsetzen, wenn dadurch sich die REST-API ändert.
Die fachspezifische REST-API kapselt die interne Datenhaltung von der nach außen sichtbaren Schnittstelle ab. Jegliche interne Verbesserung ist so lange unbedenklich, wie die fachspezifische REST-API gleich bleibt. Gerade weil bei der Definition nur fachliche Gründe eine Rolle spielen, sollte es auch nur fachliche Gründe geben, die REST-API anzupassen.
Die Flexibilität betrifft auch noch eine andere Ebene. Sollte es irgendwelche Gründe geben, das Backend auszutauschen, kann bei der Verwendung einer fachspezifischen REST-API das Frontend unverändert weiter verwendet werden. Das neue Backend muss lediglich die gleiche fachspezifische REST-API wieder zur Verfügung stellen.