Es gibt mittlerweile eine Vielzahl an Libraries, die es Applikationen in verschiedenen Programmiersprachen erlauben, auf eine Ressource (z.B. Datenbanken, WebServices etc.) zuzugreifen – beispielsweise gibt es für C++ die ODBC Library oder für Java die JDBC Library. In den Datenbanken, Dateien, oder sonstigen Informationsquellen liegen die Daten bzw. die Daten-Schicht, oder allgemeiner, die Ressourcen.
Aus Sicht der Applikation ist die Daten-Schicht (Data API) und damit auch die Ressource transparent, also herstellerunabhängig. Das ist dem Umstand zu verdanken, dass sich gewisse Standards, wie z.B. JDBC oder ODBC für Datenbanken oder XML für Textdateien etabliert haben.
OData
OData ist das Equivalent für Web-Applikation, d.h. OData ist die Daten API, die beispielsweise über Web-Services den Zugriff auf Ressourcen erlaubt. Anstelle von ODBC, JDBC oder XML, werden die Standards HTML, REST und AtomPub verwendet. Die Data API wird nicht direkt in die Applikation gelinkt, sondern über REST (Representational State Transfer) Webservices mit er Anwendung verbunden. Der Zugriff auf die Ressourcen (Datenbanken, Dateien etc.) erfolgt, wie vorher, über Standards wie ODBC, JDBC etc.
Genau genommen, kommt also zum „konventionellen“ Modell noch eine weitere Abstraktionsschicht hinzu, ich will Sie den „Web-Layer“ nennen. Diese weitere Schicht bietet theoretisch den Vorteil, von „überall“ her, Ressourcen an die eigene Applikation anzubinden – natürlich nur, wenn die Ressourcen mit dem Web verbunden sind und einen entsprechenden Web-Service zur Verfügung stellen. Dieser Web-Service wird im Jargon als OData-Publisher bezeichnet.
Des weiteren wird, aus meiner Sicht, die Applikation von den Ressourcen stärker getrennt. Es wäre beispielsweise denkbar auf die Ressourcen einer „fremden“ Firma zuzugreifen, ohne sie selbst programmieren zu müssen, so wie es bereits Google (Maps etc.) oder andere Hersteller realisiert haben. Es ist dann nicht notwendig, das entsprechende Know-How firmenintern aufzubauen, mit dem Nachteil, dass evtl. Kosten für die Nutzung der Ressourcen erhoben werden.
Request
Der Zugriff auf die OData-Ressourcen erfolgt aus Sicht der Applikation über CRUD-Operationen, also über Create-, Read-, Update-, Delete-Befehle. Diese werden über die HTTP-Operationen GET, POST, PUT und DELETE abgebildet. Parameter werden in der URL abgebildet. Will man beispielsweise in einer fiktiven Datenbank über SQL alle Anwälte ermitteln, die in Aschaffenburg ansässig sind und sich auf Mietrecht spezialisiert haben, dann würde man das in etwa so realisieren:
SELECT * from lawyers where city='Aschaffenburg' and area='rent';
Analog würde man im OData Modell einen REST-Service, z.B. getLawyers über HTTP-GET aufrufen:
http://<url>/Lawyers?city='Aschaffenburg'&area='rent'
Weitere Informationen zum Aufbau der OData URI sind hier zu finden.
Response
Die Rückgabe kann in AtomPub (Atom Publishing Protocol), JSON (JavaScript Object Notation) oder XML (Extensible Markup Langugage) erfolgen.
SDKs
Eine Auswahl an SDKs für OData-Client und -Server steht direkt bei OData.org als Link zur Verfügung.
Security
Wie sieht es mit Security im Zusammenhang mit REST aus? Eine Möglichkeit bietet das Open-Source Protokoll OAuth. Alternativ kann man HTTP-Authentifizierungsmechanismen, OpenID, HMAC etc. verwenden.
Links:
RedEyeWatching 