Связь android и web приложения посредством REST архитектуры. Часть 1 Общие понятия

Многие проекты нуждаются в написании REST-приложения под Android и в этой заметке пойдет речь о том как написать такое приложения, а также рассмотрим некоторые архитектурные решения для построения. 
    
И так, что такое  REST ?
Согласно Википедии REST   это :

	
метод взаимодействия компонентов распределенного приложения в сети Интернет, при котором вызов удаленной процедуры представляет собой обычный HTTP-запрос (обычно GET или POST; такой запрос называют REST-запрос), а необходимые данные передаются в качестве параметров запроса. 

Но как оно теперь выглядит на практике. У нас есть мобильное приложение, которое мы сейчас напишем, и нам с помощью этого приложения необходимо вызвать какой то метод и получить информацию с сервера. В данном примере мы будем получать список пользователей, а также отдельно информацию о пользователе, указав при этом id пользователя.
Каждая единица информации задается с помощью URL, которая имеет строго заданный формат. К примеру если мы хотим получить список наших пользователей, то мы будем использовать запрос типа «GET /v1/users/» . Но как мы решили что нам нужно писать именно такую строку. Давайте попытаемся расшифровать ее. 
Первым параметром мы указали GET, а это значит что мы хотим получить информацию. Каждый тип запроса имеет свое назначение. А именно:

Но как могли заметить у нас есть еще одна составляющая запроса это «/v1/». Дело в том что это версия нашего api. Если Вы разрабатываете приложение и думаете что у меня будет только одна версия то это не так и в последующем возникнет много проблем с поддержкой кода и самого приложения в целом.   Версия api также четко регулирует набор данных которые будут переданы. 
Например Вы пишите систему, где у пользователя есть определенные поля. Но проходит год-два Ваша система расширяется и Вы добавляете новые поля, некоторые удаляете или изменяете  для того же пользователя. Все отлично замечательно обновляете ПО но, оказывается не все пользователи обновили приложения по каким то причинам или тут возникает ситуация, при какой вроде и терять пользователей не хочется и заставить обновить тоже не корректно. 
Построив правильно архитектурное решения приложения, мы сможем урегулировать данную ситуацию. В своей системе на сервере мы реализовываем некий фасад взаимодействия приложения и сервера. Пользовательское приложения всегда общается условно говоря с одним сервером. Который будет принимать решения что делать дальше с нашим запросом.
    

Как видно из картинки, мы имеем единую точку входа, а внутри ее уже наш фасад определяет куда дальше следовать нашему запросу.
Таким образом указав версию api мы сможем поддерживать все в рабочем состоянии а также поддерживать нашу систему гибкой и масштабируемой.  
Разрабатывая систему необходимо продумать не только запросы которые будут поступать но и ответы, а также ошибки которые будут в системе. 
В следущей части мы уже приступим к созданию нашего приложения.