Ich habe mich gefragt, ob jemand Ratschläge zu den Vor- und Nachteilen zwischen der Verwendung von Mashery und Apigee zum Dokumentieren einer API geben könnte. Ich habe einiges evaluiert und habe ungefähr 2 Wochen Zeit, um einen Vorschlag zu machen, was ich verwenden soll. Ich habe Mashery verwendet, aber nicht Apigee genug, um die Unterschiede zu kennen.
Alle Ressourcen, auf die Sie mich verweisen könnten, oder anekdotische Ratschläge, die Sie mir geben könnten, wären sehr willkommen.
Ich habe diese Frage auch in der API Writers-Gruppe gepostet, poste aber Cross-Posting, da diese Gruppe ein breiteres Publikum hat.
Vielen Dank im Voraus.
Es ist schwierig, einen direkten Vergleich anzustellen, da Sie nicht oft jemanden finden, der Erfahrung mit der Verwendung von Mashery und Apigee hat. Von Mashery-Seite kann ich also kommentieren, was verfügbar ist, da ich mit der Lösung bestens vertraut bin.
Zur Dokumentation einer API verfügt Mashery über zwei Produktfunktionen, die allen Kunden standardmäßig zur Verfügung stehen: (1) Langform-Dokumentations-CMS (Content-Management-System) mit rollenbasierter Zugriffskontrolle und (2) interaktive Dokumentation (E/A-Dokumente) mit vollständiger Autorisierungsintegration .
Das CMS für Langform-Dokumente ist einfach. Es bietet eine einfache Möglichkeit, hierarchische Dokumente mit einem einfachen WYSIWYG-HTML-Editor oder reinem HTML zu erstellen. Sie haben auch die volle Stilkontrolle mit CSS-Vorlagen oder sogar Inline-injizierbarem CSS sowie die Möglichkeit, Remote-JS zu laden oder auch Inline-injiziertes JS auszuführen.
Beispiele für Langform:
Tribune Media Services: http://developer.tmsapi.com/docs/read/data_v1/lineups/Lineups_by_zipcode
Expedia Affiliate Network: http://developer.ean.com/docs/read/hotel_list
Für die interaktiven Dokumente bietet Mashery I/O Docs an. I/O Docs ist mit einem JSON-Schema konfiguriert und in das Entwicklerportal integriert – sodass die Autorisierungsschemata und API-Schlüssel automatisch ausgefüllt werden, wenn sich ein Entwickler anmeldet. I/O Docs ist flexibel und unabhängig von anderen API-Definitionen, was es einem technischen Redakteur ermöglicht, I/O Docs so zu konfigurieren, dass es sich nicht nur als Referenzdokument und Testtool , sondern auch als Lerntool verhält ( dh Schritt-für-Schritt-Konfiguration mit ausführlichen Beschreibungen zu Ressourcen, Methoden und Parametern).
Beispiele für E/A-Dokumente:
FoodEssentials: http://developer.foodessentials.com/io-docs (step-by-step style)
Tribune Media Services: http://developer.tmsapi.com/io-docs
EPSN: http://developer.espn.com/io-docs
Mit Mashery werden sowohl das Traffic- als auch das Portalmanagement an einem Ort durchgeführt. Es ist alles sehr eng miteinander verbunden. Das ist natürlich einer der größten Unterschiede – das Management. Auch hier verwendet Apigee im Guten wie im Schlechten Drupal als CMS, und es fungiert als separate Einheit, die verwaltet werden muss. Der Gegensatz wäre, dass der Entwicklerportal-Stack von Mashery mandantenfähiges SaaS ist und vollständig verwaltet wird.
Eine Person/Firma kam mir in den Sinn, Peter von SDK Bridge. Ich glaube, sein Unternehmen hat Dokumentationen für einen oder mehrere Mashery-Kunden sowie für Plattformen geschrieben/implementiert, die nicht zur Mashery-Familie gehören. Gut möglich, dass er schon hier ist, aber wenn nicht, vielleicht sehen Sie nach, ob er einen Vergleich liefert: http://sdkbridge.com/documentation.php -- er ist weder mit Mashery verbunden noch beschäftigt er ihn.
Haftungsausschluss: Ich bin ein Plattform-Evangelist bei Mashery (ein Evangelist für die APIs unserer Kunden) – daher kenne ich mehrere technische Redakteure und API-Architekten recht gut. :)
Viel Glück!
Monika Cellio