Thursday

Изграждане на уеб услуги на REST път

От Роджър Л. Костело

Източна страница: http://xfront.com/REST-Web-Services.html

Аз първо ще дам кратко въведение в REST и след това ще опиша как да изграждате уеб услуги в стил REST.

Какво представлява REST?

REST е термин, въведен от Рой Филдинг в неговата докторска степен. дисертация [1], за да опише архитектурен стил на мрежови системи. REST е акроним на представителния държавен трансфер.

Защо се нарича "Представително държавно прехвърляне"?

Мрежата се състои от ресурси. Един ресурс е всеки интересен елемент. Например, Boeing Aircraft Corp може да определи 747 ресурс. Клиентите могат да имат достъп до този ресурс с този URL адрес:

http://www.boeing.com/aircraft/747

Представя се ресурсът (напр. Boeing747.html). Представянето поставя клиентското приложение в състояние. Резултатът от преминаването на клиент към хипервръзка в Boeing747.html е достъпа до друг ресурс. Новото представяне поставя клиентското приложение в още едно друго състояние. По този начин клиентските приложения се променят (трансфери) с всяко представяне на ресурси -> Representational State Transfer!

Тук е обяснението на Roy Fielding за значението на Representational State Transfer:

"Представителният държавен трансфер има за цел да предизвика образа за това как се държи добре разработеното уеб приложение: мрежа от уеб страници (виртуална държавна машина), където потребителят преминава през приложение, като избира връзки (преходи на държавата), което води до следващата страница (представляваща следващото състояние на приложението) се прехвърля на потребителя и се предава за тяхното използване. "

Мотивация за REST

Мотивацията за REST беше да улови характеристиките на мрежата, които направиха уеб успешна. Впоследствие тези характеристики се използват за насочване на еволюцията на мрежата.

REST - архитектурен стил, не стандарт

REST не е стандарт. Вие няма да видите W3C да издава спецификация REST. Няма да видите IBM, Microsoft или Sun, които продават комплекти от инструменти за разработчици на REST. Защо? Тъй като REST е просто архитектурен стил. Вие не можете да бутилка този стил. Можете да го разберете само и да проектирате уеб услугите си в този стил. (Аналогично на архитектурния стил клиент-сървър. Няма стандарт клиент-сървър.)

Въпреки че REST не е стандарт, той използва стандартите:

  • HTTP
  • URL
  • XML / HTML / GIF / JPEG / и т.н. (Представителство на ресурсите)
  • текст / xml, текст / HTML, изображение / gif, изображение / jpeg и т.н. (MIME Типове)

Системата Classic REST

Мрежата е система REST! Много от тези уеб услуги, които сте използвали тези много години - услуги за поръчване на книги, услуги за търсене, онлайн услуги с речници и т.н. - са уеб услуги, базирани на REST. Уви, използвахте REST, изграждайки услугите на REST и дори не сте го познавали.

REST се занимава с "голямата картина" на мрежата. Тя не се занимава с подробности за внедряването (напр. С помощта на Java сървлети или CGI за внедряване на уеб услуга). Затова нека разгледаме примера за създаване на уеб услуга от гледна точка на "голямата картина" на REST.

Услуги за депозиране на части

Parts Depot, Inc (фиктивна компания) разполага с някои уеб услуги, за да даде възможност на своите клиенти:

  • да получите списък с части
  • да получите подробна информация за определена част
  • да подадете поръчка за покупка (PO)

Нека разгледаме как всяка от тези услуги се изпълнява по най-добрия начин.

Получаване на списъка с части

Уеб услугата предоставя URL адрес на ресурс в списъка с части. Например, клиентът би използвал този URL адрес, за да получи списъка с части:

http://www.parts-depot.com/parts

Имайте предвид, че "как" уеб услугата генерира списъка с части е напълно прозрачна за клиента. Целият клиент знае, че ако подаде горепосочения URL адрес, се връща документ, съдържащ списъка с части. Тъй като изпълнението е прозрачно за клиентите, Parts Depot има свободата да променя основното внедряване на този ресурс, без да оказва влияние върху клиентите. Това е свободно свързване.

Ето документа, който клиентът получава:

<?xml version="1.0"?>
<p:Parts xmlns:p="http://www.parts-depot.com" 
         xmlns:xlink="http://www.w3.org/1999/xlink">
      <Part id="00345" xlink:href="http://www.parts-depot.com/parts/00345"/>
      <Part id="00346" xlink:href="http://www.parts-depot.com/parts/00346"/>
      <Part id="00347" xlink:href="http://www.parts-depot.com/parts/00347"/>
      <Part id="00348" xlink:href="http://www.parts-depot.com/parts/00348"/>
</p:Parts>

Да предположим, че чрез преговори по съдържание услугата е определила, че клиентът иска представянето като XML (за обработка от машина към машина).] Имайте предвид, че в списъка с части има връзки, за да получите подробна информация за всяка част. Това е ключова характеристика на REST. Клиентът прехвърля от една държава в друга, като разглежда и избира измежду алтернативните URL адреси в документа за отговор.

Получете подробни данни за частта

Уеб услугата предоставя достъп до URL адреса на всеки отделен ресурс. Пример: Ето как клиент иска част 00345:

http://www.parts-depot.com/parts/00345

Ето документа, който клиентът получава:

<?xml version="1.0"?>
<p:Part xmlns:p="http://www.parts-depot.com"   
        xmlns:xlink="http://www.w3.org/1999/xlink">
      <Part-ID>00345</Part-ID>
      <Name>Widget-A</Name>
      <Description>This part is used within the frap assembly</Description>
      <Specification xlink:href="http://www.parts-depot.com/parts/00345/specification"/>
      <UnitCost currency="USD">0.10</UnitCost>
      <Quantity>10</Quantity>
</p:Part>

Отново спазвайте как тези данни са свързани с още повече данни - спецификацията за тази част може да бъде намерена чрез преместване на хипервръзката. Всеки документ за реакция позволява на клиента да проследява, за да получи по-подробна информация.

Подайте PO

Уеб услугата предоставя URL адрес за изпращане на PO. Клиентът създава документ за потребителски интерфейс (PO), който съответства на схемата на PO, която е разработила (и публикувала в документ на WSDL). Клиентът подава PO.xml като полезен товар на HTTP POST.

Услугата PO отговаря на HTTP POST с URL адрес на изпратената PO. По този начин клиентът може да изтегли PO по всяко време след това (за да го актуализира / редактира). ОП стана част от информацията, която се споделя между клиента и сървъра. Споделената информация (PO) получава адрес (URL) от сървъра и е изложена като уеб услуга.

Логически URL адреси срещу Физически URL адреси

Ресурсът е концептуален субект. Представянето е конкретна проява на ресурса. Този URL адрес:

http://www.parts-depot.com/parts/00345

е логически URL адрес, а не физически URL адрес. По този начин не е необходимо да има например статична HTML страница за всяка част. Всъщност, ако имаше милион части, тогава един милион статични HTML страници нямаше да са много атрактивен дизайн.

[Детайли за внедряването: Parts Depot може да внедри услугата, която получава подробни данни за конкретна част, като използва Java Servlet, който анализира низа след името на хоста, използва номера на частта за заявка на базата данни на части, формулира резултатите от заявката като XML и след това върнете XML като полезен товар на HTTP отговор.]

Като въпрос на URL стила не трябва да се разкрива използваната техника за внедряване. Трябва да имате свободата да променяте реализацията си, без да оказвате влияние върху клиентите си или да имате подвеждащи URL адреси.

Характеристики на уеб услугите на REST

Ето и характеристиките на REST:

  • Клиентски сървър: стил на взаимодействие, основаващ се на дръпване: консумиращи компоненти издърпайте изображения.
  • Без гражданство: всяка заявка от клиент до сървър трябва да съдържа цялата информация, необходима за разбирането на заявката, и не може да се възползва от съхранявания контекст на сървъра.
  • Кеш: за да се подобрят реакциите за ефективност на мрежата трябва да могат да бъдат означени като кешируеми или не кеширащи.
  • Единен интерфейс: всички ресурси са достъпни с общ интерфейс (напр. HTTP GET, POST, PUT, DELETE).
  • Наименувани ресурси - системата се състои от ресурси, които се наименуват чрез URL адрес.
  • Взаимозависимо представяне на ресурсите - представянията на ресурсите са взаимосвързани посредством URL адреси, което позволява на клиента да напредва от едно състояние в друго.
  • Слоести компоненти - посредници, като прокси сървъри, кеш сървъри, шлюзове и т.н., могат да бъдат вмъквани между клиенти и ресурси за поддръжка на производителността, сигурността и т.н.

Принципи на дизайна на уеб услугата REST

1. Ключът към създаването на уеб услуги в мрежата REST (т.е. в мрежата) е да идентифицирате всички концептуални обекти, които искате да покажете като услуги. По-горе видяхме някои примери за ресурси: списък с части, подробни данни за частта, поръчка за покупка.

2. Създайте URL адрес за всеки ресурс. Ресурсите трябва да бъдат съществителни, а не глаголи. Например, не използвайте това:

http://www.parts-depot.com/parts/getPart?id=00345

Обърнете внимание на глагола, getPart. Вместо това използвайте съществително:

http://www.parts-depot.com/parts/00345

3. Категоризирайте ресурсите си според това дали клиентите могат просто да получат представа за ресурса или дали клиентите могат да променят (добавят) ресурса. За първите, направете тези ресурси достъпни чрез HTTP GET. За по-късните, направете тези ресурси достъпни чрез HTTP POST, PUT и / или DELETE.

4. Всички ресурси, достъпни чрез HTTP GET, трябва да бъдат странични ефекти безплатно. Тоест, ресурсът просто трябва да върне представянето на ресурса. Извикването на ресурса не трябва да води до промяна на ресурса.

5. Никой мъж / жена не е остров. По същия начин, нито едно представителство не трябва да бъде остров. С други думи, поставете хипервръзки в репрезентациите на ресурсите, за да позволите на клиентите да разберат повече информация и / или да получат свързана информация.

6. Дизайн за постепенно разкриване на данни. Не разкривайте всичко в един документ за отговор. Предоставяйте хипервръзки, за да получите повече подробности.

7. Определете формата на данните за отговор, като използвате схема (DTD, W3C Schema, RelaxNG или Schematron). За тези услуги, които изискват POST или PUT към него, също така предоставя схема за уточняване на формата на отговора.

8. Опишете как да бъдат извикани вашите услуги чрез WSDL документ или просто HTML документ.

резюме

Тази статия описва REST като архитектурен стил. Всъщност това е архитектурният стил на уеб. REST описва какво прави мрежата да работи добре. Придържайки се към принципите REST, услугите ви ще работят добре в контекста на мрежата.
В бъдеща статия ще пиша за еволюцията на мрежата, използвайки принципите REST.

признание

Благодарение на Robert Leftwich и Philip Eskelin за много полезните им коментари при създаването на този документ.

Препратки

[1] http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm























No comments:

Post a Comment