8.1 Отдалечен API подход
Всички програмисти правят една и съща грешка, когато изграждат клиент-сървър архитектура. Те започват да третират заявките към сървъра като извиквания на метод .
Искате да започнете процеса на генериране на отчет на сървъра, защо не му изпратите заявка като:
http://server.com/startDocumentGeneration?paramsИ How да изтегля отчета след като приключи? За да направим това, ще напишем друг метод:
http://server.com/getDocumentСървърът HttpSessionсъхранява информация за нашия document и веднага щом documentът бъде генериран, сървърът ще го върне.
Страхотен подход. Или не?
Подходът наистина е ужасен. Работата е там, че сървърът трябва да запомни номера на documentа. С други думи, за да обработва правилно нови извиквания на методи, сървърът трябва да запомни резултатите от извикването на предишни методи.
В мрежата това е голям проблем. Интернет може да изчезне, браузърът може да се затвори. Страницата може да бъде презаредена or случайно щракната върху връзка и т.н. И сървърът ще продължи да съхранява мегаbyteи данни от предишни потребителски заявки ...
За удобна работа със сървъра не можете да очаквате, че винаги ще имате под ръка данните от предишни заявки към сървъра.
Как тогава да извикате методи на сървъра? Правилният отговор би бил ужасен: няма начин!
8.2 Подход REST
Програмистите се върнаха към основите и си спомниха, че първоначално заявката съдържаше пътя до file на сървъра:
http://server.com/path?paramsИ решихме да използваме този подход максимално.
Сега сървърът се разглежда като хранorще на данни , което е видимо отвън под формата на дърво .
Ако искате да получите списък с всички потребители, извикайте заявката:
http://server.com/usersАко искате да получите данни за потребител 113, изпълнете заявката:
http://server.com/users/113И така нататък, все в същия дух.
Още веднъж, сървърът се разглежда като хранorще на данни, което е видимо отвън под формата на дърво.
Данните могат да бъдат получени - GET заявки , модифицирани - POST заявка и изтрити - DELETE заявка .
8.3 Няма състояние
REST протоколът за взаимодействие между клиента и сървъра изисква следното condition: в периода между заявките от клиента на сървъра не се съхранява информация за състоянието на клиента.
Всички заявки от клиента трябва да бъдат изработени по такъв начин, че сървърът да получава цялата информация, от която се нуждае, за да изпълни заявката всеки път . Състоянието на сесията се запазва от страна на клиента.
По време на обработката на клиентските заявки се счита, че клиентът е в преходно състояние. Всяко отделно състояние на приложението е представено от връзки, които могат да бъдат извикани следващия път, когато клиентът посети.
8.4 Еднородност на интерфейса
Всички пътища, използвани за извличане на обекти от сървъра, са стандартизирани. Това е много удобно, особено ако получавате данни от други REST сървъри.
Всички обектни интерфейси трябва да отговарят на три условия:
Идентификация на ресурса
Всички ресурси се идентифицират в заявките с помощта на URI. Ресурсите вътре в сървъра са отделни от изгледите, които се връщат на клиентите. Например, сървърът може да изпраща данни от база данни като HTML, XML or JSON, нито един от които не е тип съхранение в сървъра.
Манипулиране на ресурси чрез изглед
Ако клиентът съхранява представяне на ресурса, включително метаданни, тогава той има достатъчно информация, за да промени or изтрие ресурса на сървъра.
„Самоописващи“ съобщения
Всяко съобщение съдържа достатъчно информация, за да разберете How да го обработите. Например, ако имате нужда от информация за потребителя, тогава сървърът ще ви върне JSON обект, където ще има полета за име, address.
Не трябва да има ситуация, в която клиентът трябва да знае, че първото число в отговора е възрастта, а второто е датата на раждане.
8.5 Кеширане
Подходът REST предполага, че заявките за данни се правят чрез HTTP протокола. Следователно обектите се получават чрез извикване на GET заявка. Това означава, че те, Howто всички ресурси, получени чрез GET заявка, са предмет на всички правила за кеширане на HTTP ресурси.
Тоест данните, получени чрез REST API, се кешират по същия начин като всички статични ресурси на уеб сървъри. красота :)