REST (на английски: Representational State Transfer) е стил софтуерна архитектура за реализация на уеб услуги. Основната идея е да се определи системен ресурс, който се променя в резултат на взаимодействието между доставчика на услуги и потребителя. Архитектурният модел REST включва взаимодействията между сървър и клиент, осъществени по време на трансфера на данни. Концепцията беше въведена за пръв път от Рой Филдинг през 2000 г. като част от неговата докторска дисертация. Филдинг е един от основните автори на HTTP протокола, под който се изпълняват REST имплементациите в повечето случаи.
Архитектурата REST е разработена успоредно с HTTP 1.1. Въпреки това, REST е обща архитектура, която може да бъде реализирана в други среди, а не само под HTTP. World Wide Web представлява най-голямото осъществяване на архитектурния стил на REST. REST – стилът обикновено се състои от клиенти и сървъри. Клиентите инициират заявки към сървърите; сървърите преработват заявките и връщат подходящи отговори. Заявките и отговорите са създадени през прехвърляне на образа на ресурси. Ресурсът може да бъде всякаква ясна и смислена концепция, която може да бъде адресирана. Представяне (анг. representation) на ресурс обикновено е документ, който намира сегашното възнамерявано състояние на ресурса.
Клиентът започва да изпраща заявки, когато е готов да направи преходът към ново състояние. Докато една или повече заявки са неизпълнени за клиента се смята, че е в преход. Представянето на всяко приложение се състои от линкове, които могат да бъдат използвани следващия път, когато клиентът избере да направи нови официални промени.
Архитектурният стил на „REST“ прилага шест ограничителни условия, като същевременно дава свобода за дизайна и имплементацията на индивидуалните компоненти:
Единственото условие на REST архитектурата, което не е задължително е „Код по поискване“. Всяко приложение (услуга), изпълняващо на гореописаните условия, може да се нарече „RESTful“. Ако нарушава дори едно от условията, то не може да бъде считано за „RESTful“.
Всяка разпространена хипермедийна система, съответстваща на архитектурния стил на „REST“ притежава нужната производителност, мащабируемост, опростеност, гъвкавост, видимост, портативност и надеждност.
RESTful уеб API (също наричано RESTful уеб service) е уеб приложение, което използва принципите на HTTP и REST. Представлява колекция от ресурси с четири дефинирани аспекта:
Таблицата показва как HTTP методите обикновено се използват, за да се създаде уеб приложение.
Ресурс | GET | PUT | POST | DELETE |
---|---|---|---|---|
Collection URI, като http://example.com/resources
|
Подрежда URL адресите и някои други детайли на членовете на колекцията. | Заменя цялата колекция с друга колекция. | Създава нов вход в колекцията. URL адресът на новия вход е определен автоматично и обикновено се връща от операцията. | Трие цялата колекция. |
Element URI, като http://example.com/resources/item17
|
Връща представяне на адресирания член на колекцията, изразена в подходящ Интернет медия тип. | Заменя адресирания член на колекцията или ако не съществува го създава. | Обикновено не се използва. | Трие адресираният член на колекцията. Третира адресираният член като собствена колекция и прави нов вход за нея. |
Методите PUT и DELETE са Idempotent_methods_and_web_applications idempotent methods. Методът GET е безопасен метод, което означава, че извикването му не причинява странични ефекти.
За разлика от SOAP – базираните уеб услуги, няма „официален“ стандарт за RESTful уеб API. Това е така, защото REST е архитектурен стил за разлика от SOAP, който е протокол. Въпреки че REST не е стандарт, REST имплементация като Уеб може да използва стандарти като HTTP, URL, XML, и др.
Единният интерфейс на REST се счита за основа на дизайна на всяка REST услуга.
Отделните ресурси се разпознават по заявките (например използвайки URIs в уеб-базирани REST системи). Самите ресурсите са отделни от изображението, което се изпраща на клиента. Например сървърът вместо да изпраща цялата база данни, изпраща HTML, XML или JSON, които представляват някакви записи в нея.
Имайки изображение на ресурса, клиента има достатъчно информация, с която може да променя или трие ресурсите от сървъра, в случай че има разрешението да го направи.
Всяко съобщение включва информация, която описва как да се обработи съобщението.
HATEOAS е ограничението, което отличава архитектурата на REST приложението от повечето архитектури на мрежови приложения. При нея клиента „общува“ с приложението изцяло чрез hypermedia, получена динамично от сървъра.
През последните години REST е широко използван в контекста на Web 2.0 приложения и внедряването на уеб услуги и SOA. Следват някои примери за неговата употреба: