Actualmente tengo una API web WCF que he dividido en dos versiones. La primera versión se ejecuta en api.mysite.com. El segundo actualmente no está publicado en producción.¿Cuál es la mejor forma de versionar una API web de WCF?
Me gustaría una forma de publicar la segunda API de modo que las solicitudes a la primera versión no se interrumpan. Mis ideas serían agregar un encabezado x-api-version
y enrutar internamente la solicitud a la API designada. Si no hay cabecera, y de esta forma a la versión 1. Consideré añadir /v1
o /v2
al principio del camino para delimitar la versión de tal manera que una solicitud para v1 v2 o podría ser:
http://api.mysite.com/v1/authentication/login
http://api.mysite.com/v2/auth/login
La única advertencia es que las solicitudes sin la versión deben funcionar y de forma predeterminada a la versión 1 (o la versión que especifique).
Aunque esto suena bien (al menos para mí), no estoy seguro de cuál sería la forma recomendada de implementar esto. Sé que siempre podría hacer algún tipo de proxy inverso pero, espero que mis soluciones puedan ser programáticas. Cuanta menos configuración se requiera por parte del servidor, mejor. Si alguien tiene ideas o enlaces a blogs/tutoriales, ¡sería fantástico!
¡Gracias de antemano!
Así es como lo hace google ** v = 1.0 ** 'http: //ajax.googleapis.com/ajax/services/search/web? V = 1.0 & rsz = 8 & q = stackoverflow' –
Veo el 'encabezado de versión' y 'versión URI' como enfoques similares, y yo los apoyaría a ambos. Tenerlo en el URI es MUY útil para los desarrolladores: hace que sea fácil experimentar con servicios a través de un navegador. También apoyaría un "URI sin versión" que redirecciona a la versión "activa" actual (esta suele ser la versión más reciente, pero es posible que tenga escenarios en los que cree nuevas versiones pero no las active públicamente). Realmente depende de tus criterios. – Adam
Después de ver los detalles de implementación, creo que tendré que inclinarme más hacia el enfoque de URI estrictamente debido a la facilidad técnica.Sin embargo, creo que puedo tomar este enfoque sin dejar de cumplir con mi requisito original de no romper los clientes de la API actual. –