2012-01-16 18 views
8

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!

+0

Así es como lo hace google ** v = 1.0 ** 'http: //ajax.googleapis.com/ajax/services/search/web? V = 1.0 & rsz = 8 & q = stackoverflow' –

+0

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

+0

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. –

Respuesta

1

Ok, lo disfrutado las respuestas que he recibido hasta ahora (gracias a los dos), pero no bastante a resolver mi problema, dadas las limitaciones y objetivos que tengo con mi API. Entonces, quería detallar la solución que he encontrado y planeo usar.

Para empezar, estoy versionando mi API a través del URI. Este es el sentido de que varias versiones de la API se verá como:

http://api.mysite.com/authentication/login 
http://api.mysite.com/v1/authentication/login 
http://api.mysite.com/v2/auth/login 
http://api.mysite.com/v3/auth/letmeinplease 
... you get the point ... 

Lo importante a destacar aquí es que si no se incluye un número de versión, entonces yo descuido a la versión 1. Este será mi actual Sin embargo, puede configurar de manera predeterminada la última versión, la última estable, etc.

Aquí vamos. Creé una carpeta en la que vivirá la aplicación (wwroot/api). Dentro de esa carpeta creé carpetas para todas las versiones: v1, v2, etc. Ahora, en IIS (7.5 para mí), creé un nuevo proyecto que tenía una raíz de aplicación de wwroot/api/v1. Luego agregué cada carpeta de versión (incluida v1) como una sub-aplicación. Esto me permite versionar la API a través del URI (como se ve arriba) sin embargo, hay una advertencia.

La herencia Web.config realmente puede ser un problema. Por lo tanto, me aseguré de desactivarlo para todas mis versiones de API. Se puede encontrar una referencia sobre cómo hacer esto en here. ¡Con esa excepción, todo funciona como un encanto! :-)

5

Microsoft tiene un artículo decente en versiones con WCF here

+0

Este es un excelente artículo para versionar. Sin embargo, creo que no cumple los objetivos que tengo para mi API. Como mencioné en un comentario a la respuesta de Erno, quiero que la API sea intuitiva. Quiero evitar el control de versiones de servicios y/o contratos específicos de cualquier manera que sea visible para el cliente. Quiero que el cliente solo vea un control de versiones de la API como un todo –

Cuestiones relacionadas