¿Cuál es una manera fácil de stub / dummy un servicio web restful?

Mocky.io le permite crear endpoints stub y especificar los datos que devuelven a través de URL públicas.

Runscope (descargo de responsabilidad, soy un fundador) le permite capturar una solicitud real una vez, luego reproducir la respuesta según sea necesario a través de Response Playback URLs.

He encontrado el uso de Sinatra realmente útil para este tipo de cosas si desea probar el código de llamada HTTP real. Puede hacer que un endpoint devuelva datos en segundos. Se requiere muy poco conocimiento de Ruby.

require 'sinatra'
require 'json'

get '/Person' do
    content_type :json
    { :id => 345, :key2 => 'John Doe' }.to_json
end

Es todo lo que necesita para devolver un objeto json simple.

Uno de los enfoques (similar al de Vinnie) es hacer una implementación local de su servicio web. Por ejemplo, su servicio web le permite iniciar sesión con un usuario y obtener una lista de usuarios en línea.

La interfaz webservice se ve así:

public interface WebService {
    public LoginResponse login(String user, String pass) throws Exception;
    public UsersOnlineResponse getOnlineUsers() throws Exception;
}

Luego, implementamos esta interfaz para webservice remoto que se utilizará en producción. La implementación remota realiza llamadas HTTP con la ayuda del cliente HTTP, recupera la respuesta y la analiza en un objeto de respuesta apropiado. Aquí está un fragmento de él:

public class RemoteWebService implements WebService {
    private AndroidHttpClient client = AndroidHttpClient.newInstance(USER_AGENT);

    @Override
    public LoginResponse login(String user, String pass) throws Exception {
        LoginResponse response = client.execute(
            createPostRequest(METHOD_LOGIN, user, pass), 
            new JsonResponseHandler(LoginResponse.class));

        handleResponse(response); // verify response, throw exceptions if needed
        return response;
    }
}

Para fines de prueba, cuando el servicio web no está disponible o se está desarrollando, implementamos el servicio web local. La implementación local toma respuestas JSON predefinidas de la carpeta assets y las analiza en un objeto de respuesta apropiado. Depende de usted cómo implementar el comportamiento del servicio web: puede ser respuestas estáticas simples o algunas respuestas aleatorias / dependientes de la validación. Aquí está la parte de ella:

public class LocalWebService implements WebService {
    private Context context;

    public LocalWebService(Context context) {
        this.context = context;
    }

    @Override
    public LoginResponse login(String user, String pass) throws Exception {
        Thread.sleep(DELAY); //emulate network delay

        if (validateParams(user, pass)) {
            return parseAssetsJson("ws/login.json", LoginResponse.class);
        } else {
            Response response = parseAssetsJson("ws/status_bad_request.json", Response.class);
            throw new WebServiceException(response);
        }
    }

    public <T> T parseAssetsJson(String filename, Class<T> klass) throws IOException {
        InputStream is = context.getAssets().open(filename);
        return JsonParser.getInstance().fromJson(new InputStreamReader(is), klass);
    }
}

A continuación, queremos cambiar entre implementaciones sin dolor. El uso de ambas implementaciones del servicio web es transparente, ya que utilizamos la interfaz del servicio WEB. Por lo tanto, configuraremos la instancia de servicio WEB al iniciar la aplicación. La clase Application se adapta a nuestras necesidades:

public class App extends Application {
    public static final boolean USE_LOCAL_WS = false;
    private static WebService webService;

    public static getWebService() {
        return webService;
    }

    @Override
    public void onCreate() {
        super.onCreate();
        webService = USE_LOCAL_WS ? new LocalWebService(this) : new RemoteWebService();
    }
}

Yo sugeriría revisar WireMock (descargo de responsabilidad - Yo lo escribí): http://wiremock.org /

Puede ejecutarlo de forma independiente en su computadora portátil, configurar respuestas stubbed y verificar que su aplicación envíe las solicitudes que esperaba.

Es configurable a través de una API Java fluida o JSON (archivos o sobre HTTP).

Terminé escribiendo una herramienta de servicio simulada con un propósito similar: https://github.com/clafonta/Mockey/wiki

Un servicio simulado es una gran herramienta para construir rápidamente UIs y validar el código de su cliente, pero puede convertirse en un agujero de conejo, por lo que le recomiendo que use algo que ya está disponible antes de construir el suyo propio. Github tiene muchos resultados cuando buscas 'mock'. Independientemente de lo que haga, aquí hay algunos obstáculos clave que puede encontrar.

• Terminas trabajando con el formato de datos/JSON incorrecto. Por ejemplo, la aplicación funciona muy bien con el servicio simulado, pero se interrumpe al golpear el servicio real porque la aplicación consume un objeto JSON, pero el servicio real devuelve una matriz de objetos JSON. Para evitar esto, puede intentar usar el esquema JSON para ayudar a resaltar modelos JSON no válidos en su servicio de simulación.

• Tu app no realiza una solicitud válida. Su servicio simulado normalmente no cuidado con la solicitud entrante. Por ejemplo, el servicio real necesita un "CustomerID"y su aplicación nunca lo pasa. Para evitar esto, puede crear una lógica de validación de "parámetro de solicitud requerido" en su servicio simulado.

• Desafíos de prueba. Su enfoque de pruebas funcionales automatizadas necesita interactuar con su herramienta de servicio simulado si desea probar cosas más allá del simple "camino feliz". Por ejemplo, ejecuta su prueba " el usuario A inicia sesión y ve 0 messages " vs. " el usuario B inicia sesión y ve 20 mensajes".

Puedes probar Jadler ( http://jadler.net ). Es una biblioteca http stubbing / burlándose en la que he estado trabajando durante algún tiempo. Debe cumplir con todos sus requisitos, creo.

Crear algunos archivos con respuestas ficticias y poner en una carpeta. Ahora vaya a la línea de comandos y ejecute lo siguiente: python-m SimpleHTTPServer

Ahora puede acceder a estos archivos y respuestas ficticias en http://:8000

Sugiero echar un vistazo a FakeRest ( https://github.com/marmelab/FakeRest ), un servidor falso solo del lado del cliente usando XMLHttpRequest monkey patching.

Descargo de responsabilidad: Yo lo escribí.

Atmo podría ser útil.

Descargo de responsabilidad: Soy el autor de atmo.

En caso de que alguien todavía esté mirando este hilo en year >= 2017. Ahora hay una herramienta gratuita que le permite crear servicios web soap y rest simulados en segundos sin la necesidad de instalar o implementar nada en su caja.

Amock.io

Puede seleccionar su método http, código de respuesta, cuerpo del mensaje de respuesta, tipo de contenido, especificar endpoint personalizado, etc.

Es muy útil para devolver datos simulados de servicios web remotos a su aplicación, cualquier tipo de app.

Descargo de responsabilidad, Desarrollé este servicio, por necesidad y lo hice gratis para que otros puedan beneficiarse de la solución.

Beeceptor (descargo de responsabilidad, soy el autor) le ayudará para el caso de uso exacto aquí. Cree un punto final de API, defina una ruta y una respuesta simuladas. Úsalo en hackatones para construir APIs simuladas en segundos.

Beeceptor es más que un servicio de burla. Es un proxy HTTP para API. Por ejemplo, si tiene una API real, use la API real como objetivo final. Beecetor intercepta el tráfico y utiliza reglas,

• cuando las reglas coinciden, se burlan de las API
• cuando no hay regla coincidencias, su punto final de destino se golpea como de costumbre.

Con Mocky.io, tendrás diferentes rutas de API, con Beeceptor tu URL base va a ser la misma todo el tiempo.

Puede hacer uso de http://maqueapp.com / para crear el servicio web simulado. Es rápido y fácil. Me enteré de ello en el episodio 157 de flexshow (¡no flexshow!)