WCF consumo de múltiples respuestas posibles REST

Question

Recientemente he comenzado a leer sobre el uso WebHttpBinding en WCF y ser capaz de consumir servicios REST, sin embargo, he estado confundido en este caso para un poco ahora.

Estoy escribiendo un servicio que hace que una sola solicitud a un API dado, sin embargo, puede devolver una de las muchas respuestas.

Por ejemplo, la respuesta genérica:

<ActualResponse>
<ResponseItem>
    <Name />
    <Area />
</ResponseItem>
</ActualResponse>

Sin embargo, si algo no válido en la petición de salida o el servicio de respuesta en sí estaba experimentando cualquier tipo de problema de una respuesta de regresar sería:

<ErrorResponse>
    <Message />
</ErrorResponse>

Pedram Rezaei tenía un gran puesto en consumo de servicios REST , que es donde tomo prestado la mayor parte de mi información de. De lo que puedo decir, podemos crear un objeto, siempre que el objeto ha definido atributos serializables. La cuestión es, no hay ninguna condición a la que la clase que se creó (ErrorResponse / ActualResponse).

No estoy seguro si debería estar mirando a algún tipo de funcionalidad TryParse que envía la solicitud inicial y captura el error si no se puede producir deserialización o si hay un enfoque más elegante.

Soy bastante nuevo en el mundo de WCF, por lo que existe la posibilidad que puede ser totalmente por alto algo!

Answer 1

Creo que puede pedir prestado un poco de práctica de SOAP, que tiene una jerarquía de esta manera:

<soap:Envelope>
    <soap:Body>
        ... message contents
    </soap:Body>
</soap:Envelope> 

No estoy sugiriendo que use jabón, estoy sugiriendo que se aprende desde el diseño empleado por SOAP. Lo que SOAP se incrusta la respuesta exitosa (o en sus palabras "real") dentro del cuerpo, o Vuelta a jabón: Fallo dentro del cuerpo.

un éxito en jabón podría tener este aspecto:

<soap:Envelope>
    <soap:Body>
        <ActualResponse>... </ActualResponse>
    </soap:Body>
</soap:Envelope> 

, mientras que un fallo podría tener este aspecto:

<soap:Envelope>
    <soap:Body>
        <soap:Fault>... </soap:Fault>
    </soap:Body>
</soap:Envelope> 

En su caso, podría tener este aspecto:

<ServiceResponse> 
     <ActualResponse> ... </ActualResponse>
</ServiceResponse> 

o

<ServiceResponse> 
     <Fault> ... </Fault>
</ServiceResponse> 

y la serialización XML es muy bueno en eso. . .

Sin embargo, parece que usted no tiene control sobre el sobre. El hecho es que se puede obtener varias respuestas diferentes. Para hacer frente a esto, se podía envolver la respuesta real recibida en un sobre XML artificial, y deserializar el resultado de que .

Si obtiene ... , se envuelve en un sobre deserializable a conseguir algo como ... , a continuación, deserializar.