Какой простой способ заглушить спокойный веб-сервис? - PullRequest
27 голосов
/ 09 января 2012

Я хочу создать приложение для Android, это приложение будет выполнять вызовы RESTful для веб-службы для получения некоторых данных.

Я знаю, каким будет интерфейс RESTful, но я не хочу создавать свои собственные реализации. Есть ли простой способ создать заглушку веб-службы RESTful, которая будет возвращать некоторые статические данные без необходимости написания полноценного приложения WS для этого?

Ответы [ 13 ]

14 голосов
/ 27 июня 2013

Mocky.io позволяет создавать конечные точки-заглушки и указывать данные, которые они возвращают через общедоступные URL-адреса.

Runscope (отказ от ответственности, я основатель) позволяет вам захватить реальный запрос один раз, а затем воспроизвести ответ по необходимости с помощью Воспроизведение ответа URL-адресов.

9 голосов
/ 02 марта 2012

Я обнаружил, что использование Sinatra действительно полезно для такого рода вещей, если вы хотите проверить реальный код вызова HTTP.Вы можете иметь конечную точку, возвращающую данные в считанные секунды.Требуется очень мало знаний по Ruby.

require 'sinatra'
require 'json'

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

Это все, что вам нужно для возврата простого объекта json.

5 голосов
/ 06 марта 2013

Один из подходов (похожих на подход Винни) заключается в локальной реализации вашего веб-сервиса. Например, ваш веб-сервис позволяет вам войти в систему и получить список пользователей онлайн.

Интерфейс веб-сервиса выглядит следующим образом:

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

Затем мы реализуем этот интерфейс для удаленного веб-сервиса, который будет использоваться в производстве. Удаленная реализация выполняет HTTP-вызовы с помощью HTTP-клиента, получает ответ и анализирует его для соответствующего объекта ответа. Вот фрагмент этого:

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;
    }
}

В целях тестирования, когда веб-сервис недоступен или разрабатывается, мы внедряем локальный веб-сервис. Локальная реализация берет предопределенные ответы JSON из папки активов и анализирует их для соответствующего объекта ответа. Вам решать, как реализовать поведение веб-сервиса: это могут быть простые статические ответы или некоторые случайные / зависящие от проверки ответы. Вот часть этого:

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);
    }
}

Далее мы хотим безболезненно переключаться между реализациями. Использование обеих реализаций веб-сервиса прозрачно, потому что мы используем интерфейс WebService. Итак, мы настроим экземпляр WebService при запуске приложения. Приложение Класс соответствует нашим потребностям:

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();
    }
}
3 голосов
/ 19 апреля 2013

Я бы посоветовал проверить WireMock (заявление об отказе - я написал): http://wiremock.org/

Вы можете запустить его автономно на своем ноутбуке, настроить отклики с заглушками и убедиться, что ваше приложение отправляет запросы, которые вы ожидали.

Настраивается через свободный Java API или JSON (файлы или по HTTP).

1 голос
/ 18 ноября 2017

Beeceptor (отказ от ответственности, я автор) поможет вам для точного использования здесь.Создайте конечную точку API, определите макет пути и ответ.Используйте его в хакатонах для создания фиктивных API за считанные секунды.

Beeceptor - это больше, чем сервис для насмешек.Это HTTP-прокси для API.Например, если у вас есть настоящий API, используйте настоящий API в качестве конечной цели.Beecetor перехватывает трафик и использует правила,

  • при совпадении правил, API-интерфейсы проверяются
  • , когда ни одно из правил не соответствует, ваша конечная точка поражается как обычно.

С Mocky.io у вас будут разные пути API, а с Beeceptor ваш базовый URL будет постоянно одинаковым.

1 голос
/ 02 августа 2013

Вы можете попробовать Jadler (http://jadler.net). Это http-библиотека stubbing / mocking, над которой я работал в течение некоторого времени. Она должна соответствовать всем вашим требованиям, я считаю.

1 голос
/ 18 марта 2013

Я закончил тем, что написал фиктивный сервисный инструмент для аналогичной цели: https://github.com/clafonta/Mockey/wiki

Макетный сервис - это отличный инструмент для быстрой разработки пользовательского интерфейса и проверки кода вашего клиента, но он может стать кроличьей ношей, поэтому я рекомендую вам использовать что-то уже существующее, прежде чем создавать свой собственный. Github имеет много результатов, когда вы ищете «макет». Независимо от того, что вы делаете, вот несколько ключевых камней преткновения, с которыми вы можете столкнуться.

  • В конечном итоге вы работаете с неверным форматом данных / JSON. Например, ваше приложение прекрасно работает с сервисом-имитатором, но разрывается при обращении к реальному сервису, поскольку ваше приложение использует объект JSON но реальный сервис возвращает массив объектов JSON. Чтобы избежать этого, вы можете попытаться использовать схему JSON, чтобы выделить недопустимые модели JSON в вашем фиктивном сервисе.

  • Ваше приложение не отправляет действительный запрос. Ваш поддельный сервис, как правило, не заботится о входящем запросе. Например, для реальной службы нужен «идентификатор клиента», и ваше приложение никогда не передает его. Чтобы избежать этого, вы можете создать некоторую логику проверки «требуемого параметра запроса» в своей фиктивной службе.

  • Проблемы с тестированием. Ваш подход к автоматизированному функциональному тестированию должен взаимодействовать с вашим вспомогательным сервисным инструментом, если вы хотите протестировать вещи, выходящие за рамки простого "счастливого пути". Например, вы запускаете тест " пользователь A, который входит в систему и видит 0 сообщений " против " пользователь B, который входит в систему и видит 20 сообщений ".

0 голосов
/ 23 октября 2016

На всякий случай, если кто-то еще просматривает эту ветку на year >= 2017. Теперь у нас есть бесплатный инструмент, который позволяет вам за считанные секунды создавать фиктивные мыла и отдыхать без необходимости устанавливать или развертывать что-либо на вашем устройстве.

amock.io

Вы можете выбрать свой метод http, код ответа, тело сообщения ответа, тип содержимого, указать пользовательскую конечную точку и т. Д.

Это очень полезно для возврата ложных данных из удаленных веб-сервисов в ваше приложение, любое приложение.

Отказ от ответственности, я разработал эту услугу по необходимости и сделал ее бесплатной, чтобы другие могли воспользоваться этим решением.

0 голосов
/ 01 июля 2016

Atmo может быть полезно.

Отказ от ответственности: я автор atmo.

0 голосов
/ 25 марта 2015

Я предлагаю взглянуть на FakeRest (https://github.com/marmelab/FakeRest), Fake Server только на стороне клиента, использующий исправления обезьяны XMLHTTPRequest.

Отказ от ответственности: я написал это.

...