Главная
Блог разработчиков phpBB
 
+ 17 предустановленных модов
+ SEO-оптимизация форума
+ авторизация через соц. сети
+ защита от спама

RESTful сервис для продажи ж/д билетов

Anna | 5.06.2014 | нет комментариев

Будучи студентом я периодично ездил домой на поезде. Так как в мои края ездило каждого лишь два прицепных вагона, о билетах доводилось заботиться предварительно. Безусловно, это было весьма неудобно и я, молодой и зеленый, стремительно написал малое приложение на Qt Framework, которое ходило не сервер УЗ и проверяло присутствие билетов. Как только возникал сокровенный билет, приложение отправляло sms.

Шли годы, возник Android, а после этого и Necessitas – порт Qt для Android. Недолго думая, я взялся за портирование приложение на платформу Android. Работа была стремительно сделана и итог был опубликован в Google Play. И здесь меня ждало разочарование… Большое число ошибок в Necessitas, не родной интерфейс Android, трудность установки и еще куча других причин сделали свое дело. Оценки получались в основном отрицательными и руки у меня стремителен опустились. Огорченный на каждый мир я удалил приложение с Play и на какое-то время забыл…

История

В августе 2012 я решил исследовать Android SDK. Я вооружился парой паршивых книг, прочитал их, словно они художественные, и сел за компьютер. Что бы обучиться писать, необходимо писать. Но что бы такого написать? Ага, сокровенное приложение для проверки наличия билетов.

Я стал перебирать все сайты, которые предлагали купить билеты УЗ и РЖД. Их оказалось достаточно много. На одном из сайтов я набрел на страницу с предложение о сотрудничестве. Стремительно связался с ними и они предложили мне RESTful API к их серверам (в последующем А). Все что требовалось – это подписать пару разных договоров. Я решил, что ничего не теряю, а вероятность купить билеты через приложение будет недурным бонусом.

Пока тянулась каждая бумажная волокита, неугасаемый пыл не давал сидеть на месте. Было решено написать приложение применяя API booking.uz.gov.ua (в последующем В) и pass.rzd.ru (в последующем С). Благо реверсить API – дело не трудное, и в конце октября было опубликовано приложение, дозволяющее проверять присутствие билетов через сервер В. После этого было обновление, которое добавило поддержку сервера С.

Время тянулось медлительно, а с полученным API появились технические задачи, решение которых происходило не так стремительно, как хотелось. Примерно где-то в конце декабря была готова новая версия Android приложения, которая дозволяла искать и приобретать билеты УЗ через сервер А.

Но запускать обновление я не торопился: что-то во каждому этом мне не нравилось. И это что-то именовалось «связанность». Я осмысливал, что я буду всецело и всецело зависеть от сервера А. Если внезапно придется разорвать все отношения с партнером, то приложение в один миг превратится в тыкву. И хорошо бы отвалилась проверка/покупка билетов – дозволено же перебраться на иной сервер. База данных пользователей и каждая их история покупок канет в Лету.

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

Суть нашего длинного диалога дозволено уместить в одно предложение: «Ты пытаешься написать приложение, а нужно думать больше масштабно, необходимо думать о предоставлении службы». Было предложено написать серверное приложение, которое являлось бы посредником между Android приложением и внешними провайдерами. Тогда каждая база пользователей и билетов была бы у меня на сервере. Падение либо отключение провайдера ЖД не ломало бы приложение. Переезд на иного провайдера либо подключение других сервисов, к примеру, авиабилетов, было бы всецело прозрачно для пользователя Android приложения.

Все это звучало безусловно же великолепно, но вот писать серверное приложение нравственно я был не готов. Но и выпускать обновление я теснее верно не собирался. Друг предложил свою поддержка в написании букинг (умоляю извинить за англицизм) сервера и мы принялись за дело.

Серверное приложение

Веб сервис написан с применением Spring MVC. Примерная схема компонентов и их взаимодействия:

Бизнес логика

Начнем рассматривать систему с ее ядра, а именно, с бизнес логики. Это одна из самых трудных частей букинг сервера. И дело даже не в реализации. Самые крупные задачи встали в процессе проектирования внешних API. Дело в том, что перед серверным приложением ставилась задача не поискапродажи именно ЖД lqvmk!/ol>
В чем же задача модели на языке java? А в том, что когда мы стали думать о портировании приложения на иную платформу, java нас не устраивала. Нам необходима была модель на ином языке. Да, тот путь, которым мы пошли – маленькая архитектурная оплошность. Но что сделано, то сделано. Т.к. модели – дюже простая штука (поля геттеры/сеттеры), то легко дозволено скормить их какому-нибудь конвертеру по типу Java -> C# либо Java -> C . Но если у вас есть идеи получше, тогда ожидаем комментариев к статье.

Источники данных

Сейчас давайте бегло пробежимся по источникам данных для нашей бизнес логики, а именно ExternalProviderAPI. Если у нас возникает новейший провайдер (скажем, автоперевозчик), все что от нас понадобится, это реализовать интерфейс ExternalProviderAPI. Да, это все. Огромнее никаких хитроумных манипуляций и модификаций в бизнес логике проводить не нужно. Только реализовать интерфейс внешнего провайдера. Таким образом, скажем, вовсе незадолго был добавлен плагин РЖД. Давать изложение универсального интерфейса ExternalProviderAPI тут я вероятно не стану.

Мультиязычность

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

Во-первых, ваш провайдер может не отдавать данные на языке, на котором были они были запрошены. Давайте пофантазируем, возможен Укрзализныця отдает данные на четырех языках: русский, украинский, английский и немецкий. А РЖД только на 2-х: русский и английский. Здесь дозволено пойти двумя путями:

  1. Если заказчик запросил данные на языке X, а провайдер данный язык не поддерживает, то он вернет данные на языке по умолчанию, скажем на английском.
  2. Отдавать данные не на языке по умолчанию, а на языке, тот, что с большей вероятностью будет больше внятен человеку, тот, что знает язык Х. Возвратимся к примеру с ЖД. Возможен заказчик запросил данные на украинском языке. В такой обстановки логичнее будет воротить итоги провайдера РЖД на русском языке. А если будут запрошены данные на немецком языке, то воротить данные на английском. Мы заложили в серверное приложение данный вариант, но в мобильном приложении пока мультиязычности нет.

Во-вторых, представьте обстановку: человек установил русский язык по умолчанию и приобрел билет Москва — Санкт-петербург. Вы удачно все сгрузили в базу данных и готовы отдать информацию по первому требованию. После этого данный человек переключает язык на английский и умоляет у вас список купленных билетов. На каком языке будут отданы станции «Москва» и «Санкт-петербург»?

  1. Самый примитивный вариант, как из базы достали, так заказчику и отдали. Купил человек билет на русском языке, в базу сохранились значения на русском языке. Мы решили не крепко крушить голову и воспользовались именно этим подходом.
  2. Сберегать в базу не фактические наименования станций, а ссылки на станции, возможен в иную таблицу, где хранятся наименования станций в разной локализации.

 

Хранение данных

Дальнейший вопрос, тот, что хотелось бы поднять, это вопрос, касающийся хранения данных. Первое, что хотелось бы подметить, в веб сервис была заложена идея субагентской схемы. Это значит, что мы можем выдать ключ и документацию субагенту, а тот в свою очередь может трудиться через наш сервер безусловно прозрачно, как словно он – исключительный пользователь системы. На всякого субагента выдаются свои базы данных. Их, к слову, в приложение целых две. Одна для хранения непрерывных данных: пользователи системы, купленные билеты и т.д. Вторая, для хранения временных данных – итогов поисковых сессий. В роли первой теперь работает MySQL, в роли 2-й — file in memory. Внутри бизнес логики все операции с данными выполняются через интерфейс Spring CrudRepository.

Гостевые пользователи

Для типичной работы бизнес логики нужно Отчетливо идентифицировать пользователя, тот, что исполняет поисковые сессии. Решается это достаточно легко – с поддержкой регистрации и токенов. Но принуждать пользователя регистрироваться со старта приложения – достаточно глупая затея. Тогда мы прибегнули к гостевым пользователям.

Источник: programmingmaster.ru

Оставить комментарий
БАЗА ЗНАНИЙ
СЛУЧАЙНАЯ СТАТЬЯ
СЛУЧАЙНЫЙ БЛОГ
СЛУЧАЙНЫЙ МОД
СЛУЧАЙНЫЙ СКИН
НОВЫЕ МОДЫ
НОВЫЕ СКИНЫ
НАКОПЛЕННЫЙ ОПЫТ
Форум phpBB, русская поддержка форума phpBB
Рейтинг@Mail.ru 2008 - 2017 © BB3x.ru - русская поддержка форума phpBB