Web-API-URL-Design und Implementierung

Question

Es ist durchaus üblich, Hinweise zum API-URL-Design zu erhalten, wo URLs im Format "/ api/v1/resource" sind und sich dann bei Änderung der API in/api/ändern können. v2 usw.

Jetzt muss dies irgendwie implementiert werden. Es gibt eine Reihe von Optionen:

• das Projekt an der Wurzel des Web-Servers bereitstellen, und lassen Sie die Routing-Regeln kümmern sich um die Handhabung des/api/v1 Teil
• das Projekt in eine deploy/api/Unterordner (virtuelles Verzeichnis), Routing-Regeln kümmern sich um die Teile/v1,/v2 usw., kennen aber den/api/Teil der URLs nicht.
• das Projekt in einem Unterordner/api/v1 (virtuelles Verzeichnis) bereitstellen. Eine neue Version der API ist insgesamt ein neues Projekt, das separat bereitgestellt wird. Das Projekt beschäftigt sich strikt mit den Ressourcen als Root-Konzept, kennt aber den/api/vX-Teil im Allgemeinen nicht.

Also, welche Methode würden Sie wählen, und warum?

Grüße, Daníel

Answer 1

Ich habe mein Projekt an der Wurzel des Unterordners im Einsatz und meine Routing-Regeln für die Versionierung Routen behandeln lassen. Ich bevorzuge es, meine Implementierung so wenig wie möglich von meiner Hosting-Umgebung abhängig zu machen, wenn ich sie in einer Umgebung bereitstellen möchte, die meine Implementierungsmethode nicht unterstützt.

SDammann.WebApi.Versioning ist die Lösung, die ich verwendet habe, um dies in einer meiner Anwendungen zu erreichen.

Aber ASP.NET and Web Tools for Visual Studio 2013 Release wird dies noch einfacher machen.