Урок за RESTful уеб услуги: Пример за REST API

Защо да използваме Restful Web Services?

Преди да разгледаме техническите подробности, е полезно да разберем защо REST стана толкова популярен. RESTful уеб услугите станаха известни поради следните причини:

1. Хетерогенни езици и среди – Това е една от основните причини, която е същата като тази, която видяхме за SOAP , както добре.

• Това позволява на уеб приложения, изградени на различни езици за програмиране, да комуникират помежду си.
• С помощта на Restful услугите, тези уеб приложения могат да се намират в различни среди; някои от тях биха могли да бъдат Windows, а други може да са на Linux.

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

Картината по-долу дава пример за уеб приложение, което има изискване да комуникира с други приложения като Facebook, Twitter и... Google.

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

Вместо това, Facebook, Twitter и Google излагат своята функционалност под формата на Restful уеб услуги. Това позволява на всяко клиентско приложение да извиква тези уеб услуги чрез REST, независимо от използваната технология.

2. Събитието на устройства – В днешно време всичко трябва да се работи подвижен устройства, независимо дали става въпрос за мобилен телефон, лаптоп или дори автомобилна система.

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

3. Събитието на Облака – Всичко се премества в облака. Приложенията бавно се местят към облачни системи, като например Azure or Amazon. Azure намлява Amazon предоставят много API, базирани на Restful архитектурата. Следователно, приложенията сега трябва да бъдат разработени по такъв начин, че да са съвместими с облака. Тъй като всички облачно-базирани архитектури работят на REST принципа, има смисъл уеб услугите да бъдат програмирани на REST-базирана архитектура, за да се използват максимално облачните услуги.

Ключови елементи на RESTful

REST уеб услугите са изминали дълъг път от създаването си. През 2002 г. Web консорциумът публикува дефиницията за WSDL и SOAP уеб услуги. Това формира стандарта за това как се имплементират уеб услугите.

През 2004 г. уеб консорциумът публикува и дефиницията на допълнителен стандарт, наречен RESTful. През последните няколко години този стандарт стана доста популярен и сега се използва от много от най-популярните уебсайтове по света, включително Facebook и Twitter.

REST е начин за достъп до ресурси, които се намират в определена среда. Например, може да имате сървър, който хоства важни документи, снимки или видеоклипове. Всичко това са примери за ресурси. Ако клиент, като например уеб браузър, се нуждае от някой от тези ресурси, той трябва да изпрати заявка до сървъра. REST услугите определят стандартен начин, по който може да се осъществи достъп до тези ресурси.

Ключовите елементи на внедряването на RESTful са следните:

1. Ресурси – Първият ключов елемент е самият ресурс. Да предположим, че уеб приложение на сървър има записи на няколко служители. Да предположим, че URL на уеб приложението е https://demo.guru99.comСега, за да получите достъп до ресурс за досиета на служители чрез REST услуги, можете да издадете командата https://demo.guru99.com/employee/1Тази команда указва на уеб сървъра да предостави данните на служителя, чийто служебен номер е 1.
2. Глаголи за заявка – Те описват какво искате да направите с ресурса. Браузърът издава команда GET, за да инструктира крайната точка, че иска да получи данни. Съществуват обаче много други налични команди, включително POST, PUT и DELETE. Така че, в случая с примера https://demo.guru99.com/employee/1, уеб браузърът всъщност издава команда GET, защото иска да получи подробности за досието на служителя.
3. Заглавки на заявката – Това са допълнителни инструкции, изпратени със заявката. Те могат да определят вида на необходимия отговор или подробностите за оторизацията.
4. Тяло на заявката – Това са данните, изпратени със заявката. Данните обикновено се изпращат в тялото на заявката, когато се направи POST заявка към REST уеб услугата. При POST извикване клиентът казва на REST уеб услугата, че иска да добави ресурс към сървъра. Следователно, тялото на заявката ще съдържа подробности за ресурса, който трябва да бъде добавен.
5. Тяло за отговор – Това е основната част на отговора. Така че, в нашия пример с RESTful API, ако отправим заявка към уеб сървъра чрез заявката https://demo.guru99.com/employee/1, уеб сървърът може да върне XML документ с всички данни за служителя в тялото на отговора.
6. Кодове за състояние на отговор – Това са общите кодове, връщани заедно с отговора от уеб сървъра. Пример за това е код 200, който обикновено се връща, когато няма грешка при връщането на отговор към клиента.

Спокойни методи

Диаграмата по-долу показва повечето глаголи (POST, GET, PUT и DELETE) и пример от REST API за това какво биха означавали.

Да предположим, че имаме дефинирана RESTful уеб услуга на мястото https://demo.guru99.com/employeeКогато клиентът отправи заявка към тази уеб услуга, той може да укаже някой от нормалните HTTP глаголи GET, POST, DELETE и PUT. По-долу е показано какво би се случило, ако съответните глаголи бъдат изпратени от клиента.

1. ПУСНИ – Това ще се използва за създаване на нов служител, използвайки RESTful уеб услугата.
2. GET – Това ще се използва за получаване на списък с всички служители, използващи RESTful уеб услугата.
3. PUT – Това ще се използва за актуализиране на всички служители, използващи RESTful уеб услугата.
4. ИЗТРИЙ – Това ще се използва за изтриване на всички служители, използващи RESTful услугата.

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

1. ПУСНИ – Това не би било приложимо, тъй като извличаме данни за служител 1, които вече са създадени.
2. GET – Това ще се използва за получаване на данните на служителя с номер 1, използвайки уеб услугата RESTful.
3. PUT – Това ще се използва за актуализиране на данните на служителя с номер 1, използвайки уеб услугата RESTful.
4. ИЗТРИЙ – Това се използва за изтриване на данните на служителя с номер 1.

Спокоен Archiтекстура

Приложение или архитектура, считани за RESTful или REST-стил, имат следните характеристики.

1. Състоянието и функционалността са разделени на разпределени ресурси – Това означава, че всеки ресурс трябва да е достъпен чрез нормалните HTTP команди GET, POST, PUT или DELETE. Така че, ако някой иска да получи файл от сървър, той трябва да може да подаде GET заявка и да получи файла. Ако иска да постави файл на сървъра, той трябва да може да подаде POST или PUT заявка. И накрая, ако иска да изтрие файл от сървъра, той може да подаде DELETE заявка.

2. Архитектурата е клиент/сървър, без запазване на състоянието, многопластова и поддържа кеширане.

• Клиент-сървър е типичната архитектура, при която сървърът може да бъде уеб сървърът, хостващ приложението, а клиентът може да бъде толкова прост, колкото уеб браузъра.
• Без състояние означава, че състоянието на приложението не се поддържа в REST. Например, ако изтриете ресурс от сървър с помощта на командата DELETE, не можете да очаквате тази информация за изтриване да бъде предадена на следващата заявка.

За да се гарантира изтриването на ресурса, ще трябва да подадете GET заявка. GET заявката ще се използва първо за получаване на всички ресурси на сървъра, след което ще трябва да се види дали ресурсът действително е изтрит.

Принципи и ограничения на RESTFul

REST архитектурата се основава на няколко характеристики, които са разгледани по-долу. Всяка RESTful уеб услуга трябва да отговаря на характеристиките по-долу, за да бъде наречена RESTful. Тези характеристики са известни още като принципи на проектиране, които трябва да се спазват при работа с RESTful-базирани услуги.

1. RESTFul клиент-сървър

   

Това е най-фундаменталното изискване на REST-базирана архитектура. Това означава, че сървърът ще има RESTful уеб услуга, която предоставя необходимата функционалност на клиента. Клиентът изпраща заявка към уеб услугата на сървъра. След това сървърът или отхвърля заявката, или я изпълнява и предоставя адекватен отговор на клиента.

2. без поданство

Концепцията за „бездържавност“ означава, че клиентът е длъжен да гарантира, че цялата необходима информация е предоставена на сървъра. Това е необходимо, за да може сървърът да обработи отговора по подходящ начин. Сървърът не трябва да съхранява никаква информация между заявките от клиента. Това е много проста, независима последователност от въпроси и отговори. Клиентът задава въпрос, а сървърът му отговаря по подходящ начин. Когато клиентът зададе друг въпрос, сървърът няма да запомни предишния сценарий от въпроси и отговори и ще трябва да отговори на новия въпрос самостоятелно.

3. Кеш

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

4. Слоеста система

Концепцията на многопластовата система е, че всеки допълнителен слой, като например междинен слой, може да бъде вмъкнат между клиента и действителния сървър, хостващ RESTFul уеб услугата. (Междинният слой е мястото, където се създава цялата бизнес логика. Това може да бъде допълнителна услуга, с която клиентът взаимодейства, преди да осъществи извикване на уеб услугата.) Но въвеждането на този слой трябва да бъде прозрачно, за да не се нарушава взаимодействието между клиента и сървъра.

5. Интерфейс/Униформа Contract

Това е основната техника за това как RESTful уеб услугите трябва да работят. RESTful работи основно на HTTP уеб слоя и използва ключовите глаголи по-долу, за да работи с ресурси на сървъра.

• POST – За създаване на ресурс на сървъра.
• GET – За извличане на ресурс от сървъра.
• PUT – За промяна на състоянието на ресурс или за актуализирането му.
• ИЗТРИВАНЕ – За премахване или изтриване на ресурс от сървъра.

REST срещу SOAP: Ключови разлики

Разработчиците често сравняват REST със SOAP, когато проектират уеб услуга. И двата позволяват комуникация между разпределени приложения, но се различават рязко по философия. REST е архитектурен стил, който използва прости HTTP глаголи и леки формати като JSON, докато SOAP е строг протокол, който разчита на XML пликове и формално споразумениеtracт. Таблицата по-долу обобщава най-важните разлики.

На практика REST е изборът по подразбиране за публични уеб и мобилни API, защото е по-бърз и по-лесен за използване, докато SOAP остава полезен за корпоративни системи, които изискват вградена сигурност и формална поддръжка.tracTS.

Създайте първата си уеб услуга Restful в ASP.NET

Сега, в този урок за REST API, ще научим как да създадем Restful уеб услуга в ASP.NET.

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

В този пример за RESTful API ще създадем нашето REST приложение в .NET, използвайки Visual Studio. Ще имаме Restful уеб услуга, която ще работи с набора от данни по-долу.

Наборът от данни по-долу представлява пример за REST API на компания, която предоставя самоучителите си въз основа на Tutorialid.

В нашия примерен урок за REST API ще имплементираме глаголите Restful по-долу.

1. ВЗЕМЕТЕ урок – Когато клиент извика този Restful API, ще му бъде предоставен целият набор от уроци, достъпни от уеб услугата.
2. ВЗЕМЕТЕ урок/Tutorialid – Когато клиент извика този Restful API, ще му бъде дадено името на урока въз основа на Tutorialid, изпратен от клиента.
3. POST урок/име на урок – Когато клиент извика този Restful API, той ще подаде заявка за вмъкване на име на урок. След това уеб услугата ще добави подаденото име на урока към колекцията.
4. ИЗТРИВАНЕ на урок/Tutorialid – Когато клиент извика този Restful API, той ще подаде заявка за изтриване на Tutorialname въз основа на Tutorialid. След това уеб услугата ще изтрие подаденото име на урока от колекцията.

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

Как да създадете първата си спокойна уеб услуга

Стъпка 1) Създайте нов проект.
Първата стъпка е да създадете празен Asp.Net уеб приложение. От Visual Studio 2013 щракнете върху опцията от менюто Файл->Нов проект.

След като щракнете върху опцията „Нов проект“, Visual Studio ще ви даде друг диалогов прозорец за избор на типа проект и въвеждане на необходимите данни. Това е обяснено в следващата стъпка.

Стъпка 2) Въведете името и местоположението на проекта.

1. Уверете се, че първо сте избрали C# уеб шаблон на ASP.NET уеб приложението. Проектът трябва да е от този тип, за да се създаде проект за уеб услуги. Като изберете тази опция, Visual Studio ще извърши необходимите стъпки за добавяне на необходимите файлове за всяко уеб-базирано приложение.
2. Дайте име на вашия проект, което в нашия случай е „Webservice.REST“.
3. След това се уверете, че сте посочили място, където ще се съхраняват файловете на проекта.

След като сте готови, ще видите създадения файл на проекта в Solution Explorer във Visual Studio 2013.

Стъпка 3) Създайте файла на уеб услугата.
Следващата стъпка е да създадете файла на уеб услугата, който ще съдържа RESTful уеб услугата.

1. Първо, щракнете с десния бутон върху файла на проекта, както е показано по-долу.

2. В този етап,
   1. Щракнете с десния бутон върху файла на проекта.
   2. Изберете опцията „Добавяне->Нов елемент“.

В диалоговия прозорец, който се появява, трябва да изпълните следното.

1. Изберете опцията WCF Service (Ajax-enabled). Избирането на файл от този тип кара Visual Studio да добави основен код, който ви помага да създадете RESTful уеб услуга. WCF е съкращение от Windows общуване FoundationWCF е библиотека за приложения на различни платформи (или на една и съща платформа), които комуникират по различни протоколи, като TCP, HTTP и HTTPS. Ajax е асинхронен. JavaСценарий и XML. AJAX позволява уеб страниците да се актуализират асинхронно чрез обмен на малки количества данни със сървъра зад кулисите.
2. След това дайте име на услугата, което в нашия случай е TutorialService.
3. Накрая щракнете върху бутона Добавяне, за да добавите услугата към решението.

Стъпка 4) Направете конфигурация.
Следващата стъпка е да се направи промяна в конфигурацията, за да може този проект да работи с RESTful уеб услуги. Това изисква промяна във файла с име web.configТози файл се появява в същия прозорец като файла на проекта за уеб услуга. Файлът Web.config съдържа всички конфигурации, които карат уеб приложението да работи правилно. Направената промяна позволява на приложението да изпраща и получава данни като чиста RESTful уеб услуга.

1. Щракнете върху файла Web.config, за да отворите кода.

2. Намерете линията .

3. Променете реда на .

Стъпка 5) Добавете нашия код за внедряване.
Следващата стъпка е да добавим нашия код за имплементация. Целият код по-долу трябва да бъде написан във файла TutorialService.svc.

1. Първата част е да добавим код, който да представя нашите данни, които ще бъдат използвани в нашата програма. Така че ще имаме списък с променливи низове със стойности „Масиви“, „Опашки“ и „Стекове“. Това ще представлява имената на уроците, достъпни чрез нашата уеб услуга за хостинг.

namespace Webservice.REST
{
[ServiceContract(Namespace = "")]
[AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)]
public class TutorialService
{
private static List<String> lst = new List<String>
(new String[] {"Arrays","Queues","Stacks"});

Стъпка 6) Дефинирайте кода за нашия метод GET.
След това ще дефинираме кода за нашия GET метод. Този код също ще се намира в същия файл TutorialService.svc. Този код ще се изпълнява всеки път, когато извикаме услугата от нашия браузър.

Методът по-долу ще бъде използван за изпълнение на описания по-долу сценарий.

• Ако потребителят иска списък с всички налични уроци, тогава кодът по-долу ще трябва да бъде написан, за да се постигне това.

[WebGet(UriTemplate = "/Tutorial")]

public String GetAllTutorial()
{
    int count = lst.Count;
    String TutorialList = "";
    for (int i = 0; i < count; i++)
        TutorialList = TutorialList + lst[i] + ",";
    return TutorialList;
}

Code Обяснение:

1. Първият ред код е най-важен. Той се използва, за да се дефинира как можем да извикаме този метод чрез URLТака че, ако връзката към нашата уеб услуга е http://localhost:52645/TutorialService.svc и добавяме „/Tutorial“ към URL, както е в http://localhost:52645/TutorialService.svc/Tutorial, горният код ще бъде извикан. Атрибутът „WebGet“ е параметър, който позволява на този метод да бъде RESTful метод, така че да може да бъде извикан чрез глагола GET.
2. Тази част от кода се използва за преминаване през нашия списък с низове в променливата 'lst' и връщане на всички тях на извикващата програма.

Стъпка 7) Върнете изхода.
Кодът по-долу гарантира, че ако се направи GET повикване към услугата Tutorial с Tutorial id, то ще върне съответното име на урока въз основа на Tutorial id.

[WebGet(UriTemplate = "/Tutorial/{Tutorialid}")]

public String GetTutorialbyID(String Tutorialid)
{
    int pid;
    Int32.TryParse(Tutorialid, out pid);
    return lst[pid];
}

Code Обяснение:

1. Първият ред код е най-важен. Той определя как можем да извикаме този метод чрез URLТака че, ако връзката към нашата уеб услуга е http://localhost:52645/TutorialService.svc и добавяме '/Tutorial/{Tutorialid}' към URL, бихме могли да извикаме уеб услугата като http://localhost:52645/TutorialService.svc/Tutorial/1, например. След това уеб услугата ще върне името на урока, който е имал идентификатор на урока 1.
2. Този раздел с код се използва за връщане на името на урока, на който е предаден идентификаторът на урока на уеб метода.

• По подразбиране, това, което трябва да се запомни, е, че каквото и да се предаде на URL в браузъра е низ.
• Но трябва да запомните, че индексът на нашия списък трябва да е цяло число, така че добавяме необходимия код, за да преобразуваме Tutorialid в цяло число.
• След това го използваме, за да достъпим позицията на индекса в нашия списък и съответно да върнем стойността на извикващата програма.

Стъпка 8) Напишете кода за POST метода.
Следващата стъпка е да напишем кода за нашия POST метод. Този метод ще бъде извикан всеки път, когато искаме да добавим низова стойност към нашия списък с уроци чрез POST метода. Например, ако искате да добавите името на урока „Тестване на софтуер“, тогава ще трябва да използвате POST метода.

[WebInvoke(Method = "POST", RequestFormat = WebMessageFormat.Json,
ResponseFormat = WebMessageFormat.Json, BodyStyle = WebMessageBodyStyle.Wrapped,
UriTemplate = "/Tutorial/{str}")]

public void AddTutorial(String str)
{
    lst.Add(str);
}

Code Обяснение:

1. Първият ред е атрибутът „WebInvoke“, който е прикачен към нашия метод. Това позволява методът да бъде извикан чрез POST извикване. Атрибутите RequestFormat и ResponseFormat трябва да бъдат посочени като JSON, тъй като при изпращане на стойности към RESTFul уеб услуга, стойностите трябва да бъдат в този формат.
2. Вторият ред код се използва за добавяне на низовата стойност, предадена чрез POST извикването, към съществуващия ни списък с низове за обучение.

Стъпка 9) Добавете метод за обработка на операцията DELETE.
Накрая ще добавим нашия метод за обработка на операцията DELETE. Този метод ще бъде извикан всеки път, когато искаме да изтрием съществуваща низова стойност от нашия списък с уроци чрез метода DELETE.

[WebInvoke(Method = "DELETE", RequestFormat = WebMessageFormat.Json,
UriTemplate = "/Tutorial/{Tutorialid}", ResponseFormat = WebMessageFormat.Json,
BodyStyle = WebMessageBodyStyle.Wrapped)]

public void DeleteTutorial(String Tutorialid)
{
    int pid;
    Int32.TryParse(Tutorialid, out pid);
    lst.RemoveAt(pid);
}

Code Обяснение:

1. Първият ред е атрибутът „WebInvoke“, който е прикачен към нашия метод. Това позволява методът да бъде извикан чрез DELETE извикване. Атрибутите RequestFormat и ResponseFormat трябва да бъдат посочени като JSON, тъй като стойностите трябва да бъдат в този формат. Обърнете внимание, че параметърът Method е зададен на „DELETE“. Това означава, че всеки път, когато издадем командата DELETE, този метод ще бъде извикан.
2. Вторият ред от код се използва за вземане на Tutorialid, изпратен чрез извикването DELETE, и впоследствие изтриване на този идентификатор от нашия списък. ( Int32 Функцията в кода се използва за преобразуване на идентификатора на Tutorial от низова променлива в цяло число.)

Изпълнение на вашата първа уеб услуга Restful

След като създадохме цялата си уеб услуга в горния раздел, нека видим как можем да стартираме услугата Tutorial, така че тя да може да бъде извикана от всеки клиент.

За да стартирате уеб услугата, моля, следвайте стъпките по-долу.

Стъпка 1) Щракнете с десния бутон върху файла на проекта – Webservice.REST.

Стъпка 2) Изберете опцията от менюто „Задай като стартиращ проект“. Това ще гарантира, че този проект ще се изпълнява, когато Visual Studio стартира цялото решение.

Стъпка 3) Следващата стъпка е да стартирате самия проект. В зависимост от браузъра по подразбиране, инсталиран на системата, съответното име на браузъра ще се появи до бутона за изпълнение във Visual Studio. В нашия случай имаме Google Chrome появявам се. Просто щракнете върху този бутон.

Изход: -

Когато проектът се изпълни, можете да отидете в секцията TutorialService.svc/Tutorial и ще получите резултата по-долу.

В горния резултат,

• Можете да видите, че браузърът извиква командата „GET“ и изпълнява метода „GetAllTutorial“ в уеб услугата. Този модул се използва за показване на всички уроци, предоставени от нашата уеб услуга.

Тестване на вашата първа уеб услуга Restful

В горния раздел вече видяхме как да използваме браузъра, за да изпълним глагола „GET“ и да извикаме „GetAllTutorial“.

1. Нека сега използваме браузъра, за да изпълним следния сценарий за използване.

GET Tutorial/Tutorialid – Когато клиент извика този Restful API, ще му бъде дадено името на урока въз основа на Tutorialid, изпратен от клиента.

В браузъра си добавете низа /1 след думата Tutorial в URLАко натиснете бутона Enter, ще получите резултата по-долу.

Сега ще видите изхода на „Queues“, който съответства на числото 1 в нашия списък с учебни низове. Това означава, че методът „GetTutorialbyID“ вече се извиква от нашата уеб услуга. Това също показва, че стойността 1 се предава успешно през браузъра към нашата уеб услуга и към нашия метод и затова получаваме правилната съответстваща стойност на „Queues“ в браузъра.

2. След това, нека използваме нашата уеб услуга, като изпълним сценария по-долу. За целта трябва да инсталирате инструмента, наречен Fiddler, който е безплатен инструмент за изтегляне.

POST Tutorial/Tutorialname – Когато клиент извика този Restful API, той ще подаде заявка за вмъкване на Tutorialname. След това уеб услугата ще добави изпратеното име на урока към колекцията.

Стартирайте Fiddler инструмента и изпълнете стъпките по-долу.

1. Отидете в секцията за съставяне на заявки. Тя се използва за създаване на заявки, които могат да бъдат изпратени до всяко уеб приложение.
2. Уверете се, че типът заявка е „POST“ и правилният URL е ударен, което в нашия случай би трябвало да е http://localhost:52645/TutorialService.svc/Tutorial.
3. Уверете се, че Content-Type е маркиран като application/json. Не забравяйте, че методът ни за POST заявка в нашата уеб услуга приема само данни в стил JSON, така че трябва да се уверим, че това е посочено, когато изпращаме заявка към нашето приложение.
4. Накрая трябва да въведем данните си. Не забравяйте, че нашият метод за POST приема параметър, наречен „str“. Така че тук ние указваме, че искаме да добавим стойност, наречена „Дървета“, към нашата колекция от имена на уроци и се уверяваме, че тя е маркирана с името на променливата „str“.

Накрая, просто щракнете върху бутона „Изпълнение“ в FiddlerТова ще изпрати заявка до уеб услугата за ПУБЛИКУВАНЕ на данните „Дървета“ към нашата уеб услуга.

Сега, когато прегледаме Учебника URL За да се покажат всички низове в нашия списък с инструкции, ще видите, че стойността на „Trees“ също е налична. Това показва, че POST заявката към уеб услугата е била успешно изпълнена и че е била успешно добавена към нашия списък с инструкции.

3. След това, нека използваме нашата уеб услуга, като изпълним сценария по-долу. За това също трябва да използваме Fiddler инструмент.

ИЗТРИВАНЕ НА Tutorial/Tutorialid – Когато клиент извика този Restful API, той ще подаде заявка за изтриване на Tutorialname въз основа на Tutorialid. След това уеб услугата ще изтрие подаденото име на урока от колекцията.

Стартирайте Fiddler инструмента и изпълнете стъпките по-долу.

1. Отидете в секцията за съставяне на заявки. Тя се използва за създаване на заявки, които могат да бъдат изпратени до всяко уеб приложение.
2. Уверете се, че типът заявка е „ИЗТРИВАНЕ“ и правилният URL е ударен, което в нашия случай би трябвало да е http://localhost:52645/TutorialService.svc/TutorialУверете се, че идентификаторът, използван за изтриване на низ в списъка, е изпратен чрез URL като параметър. В нашия REST пример изпращаме 1, така че това ще изтрие 2^nd елемент в нашата колекция, който е „Опашки“.

Накрая, просто щракнете върху бутона „Изпълнение“ в FiddlerТова ще изпрати заявка до уеб услугата за ИЗТРИВАНЕ на данните „Опашки“ от нашата уеб услуга.

Сега, когато прегледаме Учебника URL За да се покажат всички низове в нашия списък с инструкции, ще забележите, че стойността на „Queues“ вече не е налична.

Това показва, че заявката за изтриване (DELETE) към уеб услугата е изпълнена успешно. Елементът с индекс номер 1 в нашия списък с обучителни низове е успешно изтрит.

Най-добри практики за RESTful API

Изграждането на работещ REST API е само първата стъпка; изграждането на такъв, който се мащабира и остава поддържаем, изисква дисциплина. Практиките по-долу помагат да поддържате крайните си точки предвидими, сигурни и лесни за използване от други разработчици и AI агенти.

• Използвайте съществителни имена, а не глаголи, в URLs. Крайни точки като например /служители/1 са по-ясни от /getEmployee?id=1, защото HTTP глаголът вече описва действието.
• Връща смислени кодове за състояние. Изпраща се 200 за успех, 201 за създаден ресурс, 400 за лоша заявка, 401 за неоторизиран достъп, 404 за липсващ ресурс и 500 за сървърни грешки.
• Версия на вашия API. Добавяне на сегмент за версия, като например /v1/ в пътя ви позволява да развивате услугата, без да нарушавате съществуващите клиенти.
• Защитете всяка крайна точка. Използвайте HTTPS, заедно с API ключове или OAuth 2.0 токени и валидирайте всички входящи данни.
• Поддържайте пагинация и филтриране. Връщането на големи колекции в страниците поддържа отговорите бързи и намалява натоварването на сървъра.

Спазването на тези конвенции прави вашата RESTful уеб услуга интуитивна за интегриране, независимо дали потребителят е мобилно приложение, партньорска система или автоматизиран работен процес с изкуствен интелект.

Въпроси и Отговори