Die Drive-Now API und was macht der Ford Transit da eigentlich?

Im Gegensatz zu car2go bietet drive-now momentan leider (und unverständlicherweise) keine offene API für seine Fahrzeugdaten an. Nach meinem ersten Wurf für eine car2go Java Library wollte ich mich davon aber nicht stoppen lassen und habe mir einmal genauer angesehen, woher denn die Webseite ihre Daten bezieht. Erfreulicherweise findet sich dort recht schöne JSON-API, so dass dem Datenabruf (für mich war ohnehin nur der lesende Zugriff interessant) kein Problem zu sein schien.

Die Städte-Liste lädt die Webseite z.b. über https://api2.drive-now.com/cities?expand=cities – Doch ein GET auf diesen URI bringt erstmal Ernüchterung:

{"code":403,"message":"Permission denied."}

Doch nach etwas scharfem Hinsehen wird schnell klar was die Website anders macht. Das Javascript dort sendet zusätzlich einen „X-Api-Key“-Header im Request. Schickt man diesen mit, dann sieht das Ergebnis schon anders aus:

{
 "count": 8,
 "items": [
 {
 "businessAreaUrl": "https:\/\/api2.drive-now.com\/geodata\/6099\/6099.kml",
 "callCenterPhoneNumber": "+49 \/ 800 \/ 7234070",
 "carTypes": {
 "count": 0,
 "items": []
 },
 "cars": {
 "count": 0,
 "items": []
 },
 "chargingStations": {
 "count": 0,
 "items": []
 },
 "cityImageBaseUrl": "https:\/\/prod.drive-now-content.com\/fileadmin\/user_upload_global\/assets\/city\/{city}\/{color}\/{density}\/city.png",
 "countryLabel": "Germany",
 "fuelTypes": {
 "count": 0,
 "items": []
 },
 "id": "6099",
 "isoCountryCode": "DE",
 "latitude": 52.506629,
 "longitude": 13.381492,
 "mobileBusinessAreaUrl": "https:\/\/api2.drive-now.com\/geodata\/6099\/6099_mobile.kml",
 "name": "Berlin",
 "parkingSpaces": {
 "count": 0,
 "items": []
 },
 "petrolStations": {
 "count": 0,
 "items": []
 },
 "prolongAvailable": true,
 "registrationStations": {
 "count": 0,
 "items": []
 },
 "routingCityName": "berlin",
 "routingCountryName": "germany",
 "showBusinessAreaByDefault": false,
 "showChargingStationVisible": true,
 "showPetrolStationVisible": true,
 "showRegistrationStationVisible": true,
 "transmissionTypes": {
 "count": 0,
 "items": []
 }
 },
...
}

Die Struktur sieht auf den ersten Blick etwas merkwürdig aus, aber auf jeden Fall erhält man Infos über alle aktiven Städte. Die Attribute sind dabei recht selbsterklärend, so dass nicht im Detail darauf eingehen werde. Lediglich die numerische „id“ (= CityId) ist von hervorgehobener Bedeutung, die wird später nämlich noch benötigt. Auffällig sind auch die diversen leeren Arrays „mit“ fehlenden Infos: „carTypes“, „cars“, „fuelTypes“, „parkingSpaces“, …

Also die URL nochmal genauer betrachtet und am „expand=cities“ hängen geblieben. Was wenn ich „carTypes“ sehen möchte?

https://api2.drive-now.com/cities?expand=carTypes liefert die Antwort:

{
 "count": 8,
 "items": [
 {
 "businessAreaUrl": "https:\/\/dev.service.drive-now.com\/geodata\/6099\/6099.kml",
 "callCenterPhoneNumber": "+49 \/ 800 \/ 7234070",
 "carTypes": {
 "count": 6,
 "items": [
 {
 "carImageUrl": "https:\/\/de.drive-now.com\/static\/drivenow\/img\/cars\/mini.png",
 "group": "MINI",
 "make": "BMW",
 "modelIdentifier": "mini",
 "modelName": "MINI",
 "series": "MINI",
 "variant": ""
 },
 {
 "carImageUrl": "https:\/\/de.drive-now.com\/static\/drivenow\/img\/cars\/mini_clubman.png",
 "group": "MINI",
 "make": "BMW",
 "modelIdentifier": "mini_clubman",
 "modelName": "MINI Clubman",
 "series": "MINI",
 "variant": "Clubman"
 },
 {
 "carImageUrl": "https:\/\/de.drive-now.com\/static\/drivenow\/img\/cars\/mini_countryman.png",
 "group": "MINI",
 "make": "BMW",
 "modelIdentifier": "mini_countryman",
 "modelName": "MINI Countryman",
 "series": "MINI",
 "variant": "Countryman"
 },
 {
 "carImageUrl": "https:\/\/de.drive-now.com\/static\/drivenow\/img\/cars\/bmw_1er.png",
 "group": "BMW",
 "make": "BMW",
 "modelIdentifier": "bmw_1er",
 "modelName": "BMW 1er",
 "series": "1er",
 "variant": ""
 },
 {
 "carImageUrl": "https:\/\/de.drive-now.com\/static\/drivenow\/img\/cars\/bmw_activee.png",
 "group": "BMW",
 "make": "BMW",
 "modelIdentifier": "bmw_activee",
 "modelName": "BMW ActiveE",
 "series": "ActiveE",
 "variant": ""
 },
 {
 "carImageUrl": "https:\/\/de.drive-now.com\/static\/drivenow\/img\/cars\/bmw_active_e.png",
 "group": "BMW",
 "make": "BMW",
 "modelIdentifier": "bmw_active_e",
 "modelName": "BMW ACTIVE E",
 "series": "ACTIVE E",
 "variant": ""
 }
 ]
 },
 "cars": {
 "count": 0,
 "items": []
 },
 "chargingStations": {
 "count": 0,
 "items": []
 },
...

Siehe da: Fahrzeugtypen! Und auch für die anderen Arrays funktioniert das wunderbar. Auch ein „expand=full“ ist verfügbar und liefert die Inhalte aller Arrays, wobei die Ladezeiten hier vermuten lassen, dass man sich damit bei den Sys-Admins von Drive-Now keine Freunde macht.

Etwas fokussierter wird das ganze aber mit folgender URI: https://api2.drive-now.com/cities/4604?expand=full Das Ergebnis sind alle Daten für die CityId 4604 (München). Auch die anderen expand-Werte funktionieren hier wieder.

Aber es geht noch spezifischer: https://api2.drive-now.com/cities/4604/cars liefert ausschließlich die Autos für München, ohne die City Informationen als Wrapper-Objekt.

Im Ergebnis des „expand=cities“-Aufrufes kann man außerdem sehen, dass unter https://api2.drive-now.com/geodata/4604/4604.kml bzw. https://api2.drive-now.com/geodata/4604/4604_mobile.kml ein KML des jeweiligen Geschäftsgebietes zu finden ist (wobei ich noch keine Muse hatte den Unterschied der _mobile Version näher zu betrachten. Infos dazu gerne in die Kommentare). Im Gegensatz zu den anderen URIs, ist für die KMLs kein API-Key notwendig.

Wirklich erheiternd wird das ganze allerdings, wenn man sich das Javascript der Webseite etwas genauer ansieht, weil man z.B. auf der Suche nach einem funktionierenden API-Key zum testen ist. Dort finden sich nämlich solche Schmankerl (URLs leicht verfremdet):

 getNApiUrl: function() {
 return this.napiUrl = "entw" === this.getEnv() || "dev" === this.getEnv() ? "https://xxx.service.drive-now.com/" : "stage" === this.getEnv() ? "https://other-xxx.service.drive-now.com/" : "https://api2.drive-now.com/", this.napiUrl

Nicht weiter schlimm, schließlich fehlt der API-Key? Nunja:

 return r.getEnv() === "entw" || r.getEnv() === "dev" ? t = "ichBinDerDevAPIKey" : r.getEnv() === "stage" ? t = "ichBinDerStageAPIKey" : t = "ichBinDerDevAPIKey", $("html").hasClass("phmode") ? $.extend(e, {

Aber Entwicklungssystem sind doch bestimmt nicht von extern erreichbar! Nunja²:

{
 "businessAreaUrl": "https:\/\/dev.service.drive-now.com\/geodata\/1774\/1774.kml",
 "callCenterPhoneNumber": "+49 \/ 800 \/ 7234070",
 "carTypes": {
 "count": 4,
 "items": [
 {
 "carImageUrl": "https:\/\/de.drive-now.com\/static\/drivenow\/img\/cars\/mini.png",
 "group": "MINI",
 "make": "BMW",
 "modelIdentifier": "mini",
 "modelName": "MINI",
 "series": "MINI",
 "variant": ""
 },
 {
 "carImageUrl": "https:\/\/de.drive-now.com\/static\/drivenow\/img\/cars\/bmw_1er.png",
 "group": "BMW",
 "make": "BMW",
 "modelIdentifier": "bmw_1er",
 "modelName": "BMW 1er",
 "series": "1er",
 "variant": ""
 },
 {
 "carImageUrl": "https:\/\/de.drive-now.com\/static\/drivenow\/img\/cars\/for_transit_100_d.png",
 "group": "FOR",
 "make": "FOR",
 "modelIdentifier": "for_transit_100_d",
 "modelName": "FOR TRANSIT 100 D",
 "series": "TRANSIT 100",
 "variant": "D"
 },
 {
 "carImageUrl": "https:\/\/de.drive-now.com\/static\/drivenow\/img\/cars\/for_transit_80_d.png",
 "group": "FOR",
 "make": "FOR",
 "modelIdentifier": "for_transit_80_d",
 "modelName": "FOR TRANSIT 80 D",
 "series": "TRANSIT 80",
 "variant": "D"
...

Doch, ist es! Und es ist spannend, denn die letzten beiden Fahrzeugtypen kommen doch eher überraschend. Ob das als Ankündigung zu verstehen ist oder die Entwickler eine merkwürdige Auswahl an Test-Daten getroffen haben bleibt aber natürlich offen.

Der Fairness halber habe ich Drive-Now vor > 2 Wochen auf ihr eigenes „Überangebot“ an APIs hingewiesen. Trotz Versprechen das an die Technik weiterzuleiten, ist (trotz zwischenzeitlichem Javascript-Code-Update auf der Seite) aber bisher alles weiterhin frei zugänglich.

Meine Anfrage nach einem eigenen API-Key wurde außerdem leider ohne weitere Begründung abgelehnt.

Client/Server Validierung

In den letzten Monaten und Jahren habe ich mich bei diversen Gelegenheiten mit RESTful APIs und der Entwicklung von Clients für selbige beschäftigt. Die Frameworks dafür sind zahllos und für jeden Geschmack ist schnell etwas passendes gefunden. Mit wenigen Zeilen Code steht ein einfacher Server und auch ein hübscher Client ist schnell gehackt. Die Konzepte dahinter sind genau so vielfältig, wie clever.

Einen Aspekt habe bisher aber noch nirgendwo zufriedenstellend gelöst gesehen: Validierung. Als Benutzer möchte man das Feedback möglichst früh und vollständig. Client-Validierung ist also ein muss. Andererseits traut der geneigte Entwickler niemals einem Client. Validierung auf dem Server ist also nicht nur ebenfalls ein muss – und sollte dann auch noch mit der Client-Validierung zusammen passen. Was passiert also momentan? Die Validierung wird doppelt (oder gar noch öfter, wenn man es mit mehreren Clients zu tun hat) und – damit es richtig Spaß macht – auch noch in verschiedenen Sprachen (wenn man nicht gerade auf dem Server auch mit Javascript arbeitet) implementiert. Bleibt die Frage: Warum?!

Die Lösung, die ich mir vorstelle, sieht ungefähr so aus (Beispielhaft für meinen Technologie Stack, aber sicher auch auf andere Technologien übertragbar):

Validierungsregeln auf Server-Seite über Bean Validation (Das funktioniert bereits wunderbar):

public class User implements Serializable {
 @NotEmpty
 @Email
 private String email;

 @Size(min=5)
 @Pattern(regexp = "[a-zA-Z]*")
 private String username;

 @Size(min=8)
 private String password;
}

Validierung dann durchgeführt durch den Spring MVC Controller. (Das „schema“-Attribut der @Controller Annotation ist Wunschdenken, der Rest funktioniert ebenfalls schon)

@Controller(schema=SchemaProvider.AUTO)
public class UserController {

 @RequestMapping(value = "/user", method = RequestMethod.POST)
 public String saveUser(@Valid User user, BindingResult bindingResult) {
  /* ... */
 }

}

Dank des „SchemaProvider.AUTO“ veröffentlicht der Controller die Meta(/Validierungs)-Daten unter /user?schema als JSON Schema. Eine Grundlage dafür liefert evtl. dieser Pull Request für das Jackson JSON Schema Module. Das Ergebnis sähe dann vielleicht so aus:

{
 "title": "User Schema",
 "type": "object",
 "properties": {
  "email": {
   "type": "string",
   "pattern": "[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,4}"
  },
  "username": {
   "type": "string",
   "pattern": "[a-zA-Z]*",
   "minimum": 5
  },
  "password": {
   "type": "string",
   "minimum": 8
  }
 },
 "additionalProperties": false,
 "required": ["email", "username", "password"]
}

Das wiederum kann Angular Schema Form benutzen, um mit minimalem Code ein hübsches Formular zu zaubern und live zu validieren (siehe die Beispiele):

[
 "email",
 "username",
 "password",
 {
  "type": "submit",
  "style": "btn-info",
  "title": "OK"
 }
]

IMHO wäre das eine sehr elegante Lösung, die mit minimalem Code-Aufwand auskommt und die Validierungsregeln relativ einfach synchronisiert. Denkbar wäre z.B. auch die Regeln aus dem JSON Schema für die Validierung in Mobile Apps zu verwenden.

Nachteile? Man benötigt bereits bei der Anzeige des Formulars einen zusätzlichen Server-Aufruf, was in manchen Situationen schmerzen kann. Außerdem funktioniert das natürlich nur für ein Set an Standardvalidierungen. Will man z.B. sicherstellen, dass die E-Mail-Adresse auch unique ist, dann wird die Sache schon etwas komplizierter – Aber nicht unlösbar!

Mein neues Bastelprojekt für die Winterzeit ist jedenfalls gefunden – Ich will das haben!

Essen aus dem Internet

Ich bestelle wirklich gerne im Internet und es gibt wohl kaum etwas, das ich noch nicht bei Amazon bestellt hätte. Lebensmittel gehörten bis jetzt allerdings nicht dazu. Als mich dann die Meldung erreichte, dass Amazon jetzt auch Lebensmittel (Affili-Link) verkauft, war ich mir sicher, dass sich das schnell ändern würde. Anfangs waren viele Artikel noch versandkostenfrei zu haben, so dass ich stark versucht war 0,39 € in eine Banane zu investieren und diese dann gleich vor den Augen des DHL-Boten zu verspeisen. Zunächst hat dann aber doch die Vernunft gesiegt und bevor mein Spieltrieb sich wieder durchsetzen konnte waren die Versandkosten dann auch schon auf unattraktive 6,90 € gestiegen. Da die Artikelpreise nicht so niedrig waren, dass sich eine Bestellung dennoch gelohnt hätte, war die Idee für mich als Schwaben damit auch schon wieder gestorben.

Letzte Woche gab es dann aber einen 25 € Gutschein für Froodies, einem der Lebensmittelhändler bei Amazon, für attraktive 6 € bei Dailydeal, was dann den Einkauf dann, trotz Versandkosten, zum Schnäppchen werden lies. Also Gutschein gekauft, Warenkorb mit Waren im Wert von gut 25 € vollgeladen und ab zur Kasse. Nach Eingabe der Adressdaten dann die erste Überraschung: Mein Rum wurde aus meinem Warenkorb entfernt, da er nicht mehr lieferbar war. Als zurück in den Shop und noch einmal nachgeschaut. Zu meiner großen Verwunderung hatte sich das Sortiment deutlich reduziert. Nach etwas suchen folgte dann des Rätsels Lösung:

Derzeit sehen Sie das Gesamtsortiment aus dem froodies Lebensmittel Online Shop, welches unter Umständen von dem an Ihrem Wohnort lieferbaren Sortiment abweichen kann.

Bitte melden Sie sich hier an oder geben Sie nachfolgend Ihre Postleitzahl ein, damit wir Ihnen das für Sie verfügbare Sortiment anzeigen können.

Also kein Rum für Claus, Warenkorb anderweitig gefüllt und dann eben (bis auf eine Flasche Guinness) alkoholfrei bestellt. Das war Mittwoch Abend.

Montag Mittag klingelt dann mein Handy und ein freundlicher Mitarbeiter von Froodies ist am Apparat. Ein Teil meiner Frühstücksflocken (tolles Wort ;-)) war nicht mehr lieferbar. Mir blieb also nichts anderes übrig, als die Bestellung noch einmal zu ändern.

Heute kam dann die Leiferung per DPD. 12,20 kg laut Paketaufkleber. Im Großen und Ganzen war alles ok, nur die Pringles hören sich an, als hätten sie den Transport nicht wirklich überlebt. Ausgepackt sah das dann so aus:

Was auf dem Bild (und in der Lieferung) leider fehlt: Das Guinness. Ich bin gespannt wie der Support auf meine Mail deswegen reagiert und ob ich Ersatz geliefert bekomme (Erstattung der paar Cent empfände ich in dem Fall nicht als faire Lösung).

Eines hat mich dann aber doch schockeirt: Die Unmengen an Verpackungsmaterial (die Bionade dient zum Größenvergleich):

Mir ist durchaus klar, dass Glasflaschen gut eingepackt sein wollen und auch Krümelkekse bei den Kunden eher schlecht ankommen, aber so viel Müll ist wirkt dann doch „leicht“ übertrieben.

Ich warte jetzt mal noch ab, wie der Support wegen des fehlenden Bieres verhält, aber in Zukunft werde ich dann wohl doch weiter meine lokalen Einzelhändler dem Internet vorziehn, falls es mir an Lebensmitteln mangelt.

Edit: Inzwischen kam Antwort vom Support:

Bitte entschuldigen Sie dieses Versäumnis. Wir werden Ihnen eine Flasche Guiness nachsenden.

Klingt also gut.

Edit 2:

Das fehlenden wurde in der Tat 2 Tage später nachgeliefert. Der Verpackungswahnsinn wurde dabei fortgesetzt:

Auch wenn die Abwicklung damit insgesamt ganz gut war, bleibe ich doch bei meinem Fazit: Lebensmittel kommen bei mir weiterhin aus dem Supermarkt.