В света на съвременната разработка на софтуер интерфейсите за програмиране на приложения (API) са се превърнали в основата на безпроблемния обмен на данни между различни софтуерни системи. Като доставчик на API разбирам критичната роля, която кодовете за състоянието на HTTP играят в отговорите на API. Тези кодове на състоянието са като табели на цифрова магистрала, насочвайки разработчици и потребители чрез сложния пейзаж на заявки за данни и отговори. В тази публикация в блога ще се задълбоча в значението на кодовете за състоянието на HTTP в отговорите на API, изследвайки тяхното значение и как те влияят върху цялостното преживяване на API.
Разбиране на кодовете за състоянието на HTTP
Кодовете на състоянието на HTTP са три цифрови числа, върнати от сървър в отговор на HTTP заявка на клиента. Те предоставят стандартизиран начин за предаване на резултата от заявка, независимо дали тя е била успешна, срещна грешка или изисква допълнителни действия. Първата цифра на кода на състоянието показва общата категория на отговора, докато останалите две цифри предоставят по -конкретна информация.
1xx: Информационен
Кодовете на състоянието 1xx се използват предимно за информационни цели. Те посочват, че сървърът е получил заявката и продължава да я обработва. Тези кодове рядко се наблюдават при ежедневните взаимодействия на API, тъй като те се използват главно за междинни отговори по време на фазата на договаряне на заявка. Например a100 продължетеКодът на състоянието казва на клиента, че може да продължи с изпращането на останалата част от заявката.
2xx: Успех
Кодовете на състоянието 2xx означават, че заявката е била получена успешно, разбрана и обработена от сървъра. Това е най -желаният резултат за всяко искане на API. Някои от често използваните 2xx кодове на състоянието в отговорите на API включват:
- 200 ОК: Това е най -основният код за успех. Той показва, че заявката е била успешна и сървърът е върнал заявените данни. Например, когато клиентът поиска списък с продукти от E -търговия API, a
200 ОККодът на състоянието с данните на продукта в тялото на отговора означава, че заявката е била изпълнена успешно. - 201 създаден: Този код се използва, когато на сървъра е създаден нов ресурс. Например, ако клиент изпрати заявка за публикация за създаване на нов потребителски акаунт в API за удостоверяване, a
201 създаденКодът на състоянието, заедно с подробностите на новосъздадения потребител, показва, че акаунтът е създаден успешно. - 204 Без съдържание: Този код на състоянието се връща, когато заявката е била успешна, но няма съдържание за връщане. Например, когато клиент изпраща заявка за изтриване, за да премахне ресурс от сървъра, a
204 Без съдържаниеКодът на състоянието показва, че ресурсът е бил успешно изтрит.
3xx: Пренасочване
Кодовете на състоянието на 3xx се използват, за да посочат, че клиентът трябва да предприеме допълнителни действия, за да попълни заявката. Това обикновено включва пренасочване на клиента към различен URL адрес. Някои общи кодове на състоянието на 3xx включват:
- 301 се премести постоянно: Този код показва, че исканият ресурс е бил постоянно преместен в нов URL адрес. Клиентът трябва да актуализира своите записи и да използва новия URL адрес за бъдещи заявки.
- 302 намерени: Подобно на
301, но пренасочването е временно. Клиентът трябва да продължи да използва оригиналния URL адрес за бъдещи заявки.
4xx: Клиентна грешка
Кодовете на състоянието 4xx сигнализират, че клиентът е направил грешка в заявката. Това може да се дължи на невалиден вход, неоторизиран достъп или други странични проблеми. Някои добре - известни 4xx кодове на състоянието са:
- 400 лоша заявка: Този код показва, че сървърът не може да разбере заявката поради невалиден синтаксис. Например, ако клиент изпрати злоупотребяван с JSON полезен товар в заявка за пост до API, сървърът може да върне a
400 лоша заявкаКод на състоянието. - 401 Неразрешено: Това означава, че клиентът трябва да се удостоверява за достъп до искания ресурс. Например, ако клиентът се опита да получи достъп до защитена крайна точка на API, без да предоставя валидни идентификационни данни за удостоверяване, сървърът ще отговори с a
401 НеразрешеноКод на състоянието. - 403 Забранено: Този код на състоянието показва, че клиентът е удостоверен, но няма разрешение за достъп до искания ресурс. Например, редовен потребител, който се опитва да получи достъп до администратор - само крайната точка на API ще получи a
403 ЗабраненоОтговор. - 404 не е намерен: Това е един от най -познатите кодове на състоянието. Това означава, че исканият ресурс не може да бъде намерен на сървъра. Например, ако клиентът поиска, съществуваща API крайна точка, сървърът ще върне a
404 не е намеренКод на състоянието.
5xx: Грешка в сървъра
Кодовете на състоянието на 5xx показват, че има грешка от страна на сървъра. Това може да се дължи на погрешно конфигурация на сървъра, грешка в сървърния код или други вътрешни проблеми. Някои общи кодове на състоянието на 5xx са:
- 500 вътрешна грешка в сървъра: Това е общ код за грешка, който показва, че нещо се е объркало на сървъра. Това може да се дължи на грешка в базата данни, кодова грешка или други непредвидени проблеми.
- 503 услуга недостъпна: Този код показва, че сървърът временно не е в състояние да се справи с заявката. Това може да се дължи на поддръжка, претоварване или други временни проблеми.
Значение на кодовете за състоянието на HTTP в отговорите на API
Като доставчик на API, използването на правилните кодове на състоянието на HTTP в отговорите на API е от решаващо значение поради няколко причини:
Ясна комуникация
Кодовете на състоянието на HTTP предоставят ясен и стандартизиран начин за предаване на резултата от заявка. Разработчиците могат лесно да разберат дали заявката е била успешна, срещна грешка или изисква допълнителни действия въз основа на кода на състоянието. Това опростява процеса на разработка и намалява времето, прекарано за отстраняване на грешки.
Обработка на грешки
Правилното използване на кодовете на състоянието помага на разработчиците да прилагат ефективни грешки - механизми за обработка в техните приложения. Например, ако клиент получи a400 лоша заявкаКод на състоянието, той може да подкани потребителя да коригира входа. Ако a500 вътрешна грешка в сървърае получен, клиентът може да информира потребителя, че има проблем от страна на сървъра и да опита отново заявката по -късно.
Използваемост на API
Добре - дефинираните кодове на състоянието подобряват използваемостта на API. Когато разработчиците знаят какво да очакват от кодовете на състоянието, те могат да изграждат по -стабилни и надеждни приложения. Това от своя страна увеличава приемането на API и повишава цялостното потребителско изживяване.
Реални - Световни примери
Нека разгледаме някои реални - световни примери за това как кодовете на състоянието на HTTP се използват в отговорите на API. Да предположим, че имаме API за фармацевтична компания, която предоставя информация за активни фармацевтични съставки катоАзасетрон хидрохлорид,ГуайфенезиниПиразинамид.
- Успешна заявка: Клиент изпраща заявка за получаване на API, за да извлече информация за Guaifenesin. Ако заявката е успешна, сървърът връща a
200 ОККод на състоянието, заедно с подробна информация за Guaifenesin в тялото на отговора. - Клиентна грешка: Клиент изпраща заявка за публикация, за да създаде нов запис за съставка, но полезният товар на JSON в заявката липсва задължително поле. Сървърът връща a
400 лоша заявкаКод на състоянието, което показва, че заявката е невалидна. - Грешка в сървъра: Поради прекъсване на базата данни, сървърът не е в състояние да обработи заявка за извличане на информация за пиразинамид. Сървърът връща a
500 вътрешна грешка в сървъраКод на състоянието, информиране на клиента, че има проблем от страна на сървъра.
Водещ контакт за обществени поръчки
Ако се интересувате от интегриране на нашите API във вашите приложения или имате въпроси относно данните, които предоставяме за фармацевтични съставки, ние ви насърчаваме да се свържете с нас за поръчки и по -нататъшни дискусии. Нашите API са предназначени да предоставят точна и нагоре - да срещат информация за различни активни фармацевтични съставки, които могат да бъдат безценни за вашите бизнес операции. Независимо дали сте фармацевтичен производител, изследователска институция или друга организация, нуждаеща се от надеждни услуги на API, ние сме тук, за да ви помогнем.
ЛИТЕРАТУРА
- Fielding, RT, Gettys, J., Mogul, JC, Frystyk, H., Masinter, L., Leach, P., & Berners - Lee, T. (1999). Протокол за хипертекстов трансфер - HTTP/1.1. RFC 2616.
- Reschke, J. (2014). Протокол за прехвърляне на хипертекст (HTTP/1.1): семантика и съдържание. RFC 7231.