HTTP Requests: CRUD
Previously, we have learnt about the basics of asynchronous Javascript. Before we learn more about asynchronous Javascript, we need to know about HTTP requests and CRUD operations because they are one of the most common asynchronous operations in our web applications.
What is an HTTP request?
You may be wondering what happens behind the scenes when you enter the medium.com URL in your browser. The browser is actually sending a GET request to the server and requesting it for resources which are then served by the server. Similarly, when we sign up on Facebook, we are sending a POST request to the server which means that we are sending/uploading new data to the server.
An HTTP request is a message sent by a client to a server to request specific information or resources. The request typically includes the HTTP method (usually GET, POST, PUT, or DELETE ),the URL of the requested resource, and various headers that provide additional information about the request. As a response, the server will send a status code and the type of data it is going to send. Apart from reading data, HTTP requests are also used for performing CRUD operations — Create, Read, Update and Delete.
One thing we should know is that HTTP is a connection-less protocol. This means that HTTP establishes a TCP connection after a three-way handshake is performed , and once the request is completed, the connection is broken. If the client makes any further requests, then a new connection needs to be established.
Example of an HTTP request:
In the above example, GET is the HTTP method, HTTP 1.1 is the HTTP version and medium.com is the URL where we are sending the request.
Example of a server response:
In the above example, 200 is the status code which implies that the request was successful and Content-Type tells us the type of data which the server is sending.
Types of HTTP requests
- GET (Read) : GET requests allow us to read data from a server without modifying it. If you call GET on the same URL 10 times in a row, you should get the same response on the first call that you get on the last call as GET requests never modify the resource. Example: A simple GET request to view a profile on Facebook. Successful GET requests return the status code 200.
- POST request (Create): POST requests allow us to save new data/resources on the server. Let’s say that we want to create a new user on Facebook and save it to the database. In this case, we need to use a POST request. A successful POST request will return the status code of 201.
- PUT request (Update): If we want to update existing resources, we use the PUT request. Let’s say that we want to change the mobile number for a user on Facebook. In that case , we need to use a PUT request. A successful PUT request will return a status code of 200.
- DELETE request (Delete): DELETE method allows us to delete a resource completely from the system. Suppose we want to delete a Facebook user, we would use the DELETE request. If we use the GET request on a resource after using the DELETE request, the deleted item will not appear. A successful DELETE request will return a code of 204.
HTTP Status Codes
- 100 to 199: These are Informational codes which imply some information about the request
- 200 to 299: These are Success Messages. 200 stands for OK, 201 stands for Created, 202 stands for Accepted, 204 for No content.
- 300 to 399: These are redirection messages used when the user is being redirected to another URL . For example, 301 code is given when the resource is moved permanently to a new URL and we are being directed to the new URL.
- 400 to 499: These codes are given when there is an error on the client side. Examples: 400 Bad Request, 401 Unauthorized , 403 Forbidden, 404 Not found etc.
- 500 to 599: These codes are given when there is an error on the server side. Examples: 500 Internal Server Error and 502 Bad Gateway
It is important to know about HTTP requests as a web developer because we deal with HTTP requests all the time in web applications. Without the knowledge of HTTP requests, we will never fully understand how API calls work. From the next blog, we will go back to asynchronous Javascript and learn about Promises and Callbacks.
Автоматизация Для Самых Маленьких. Заметки. RESTful API
Эта статья — одна из обещанных коротких заметок по ходу цикла статей Автоматизация Для Самых Маленьких.
Поскольку основным способом взаимодействия с IPAM-системой будет RESTful API, я решил рассказать о нём отдельно.
Воздаю хвалы архитекторам современного мира — у нас есть стандартизированные интерфейсы. Да их много — это минус, но они есть — это плюс.
Эти интерфейсы взаимодействия обрели имя API — Application Programming Interface.
Одним из таких интерфейсов является RESTful API, который и используется для работы с NetBox.
Если очень просто, то API даёт клиенту набор инструментов, через которые тот может управлять сервером. А клиентом может выступать по сути что угодно: веб-браузер, командная консоль, разработанное производителем приложение, или вообще любое другое приложение, у которого есть доступ к API.
Например, в случае NetBox, добавить новое устройство в него можно следующими способами: через веб-браузер, отправив curl’ом запрос в консоли, использовать Postman, обратиться к библиотеке requests в питоне, воспользоваться SDK pynetbox или перейти в Swagger.
Таким образом, один раз написав единый интерфейс, производитель навсегда освобождает себя от необходимости с каждым новым клиентом договариваться как его подключать (хотя, это самую малость лукавство).
Содержание
- REST, RESTful, API
- Структура сообщений HTTP
- Стартовая строка
- Заголовки
- Тело HTTP-сообщения
- HTTP GET
- HTTP POST
- HTTP PUT
- HTTP PATCH
- HTTP DELETE
- CURL
- Postman
- Python+Requests
- SDK Pynebtbox
- SWAGGER
REST, RESTful, API
Ниже я дам очень упрощённое описание того, что такое REST.
Начнём с того, что RESTful API — это именно интерфейс взаимодействия, основанный на REST, в то время как сам REST (REpresentational State Transfer) — это набор ограничений, используемых для создания WEB-сервисов.
О каких именно ограничениях идёт речь, можно почитать в главе 5 диссертации Роя Филдинга Architectural Styles and the Design of Network-based Software Architectures. Мне же позвольте привести только три наиболее значимых (с моей точки зрения) из них:
- В REST-архитектуре используется модель взаимодействия Клиент-Сервер.
- Каждый REST-запрос содержит всю информацию, необходимую для его выполнения. То есть сервер не должен помнить ничего о предыдущих запросах клиента, что, как известно, характеризуется словом Stateless — не храним информацию о состоянии.
- Единый интерфейс. Реализация приложения отделена от сервиса, который оно предоставляет. То есть пользователь знает, что оно делает и как с ним взаимодействовать, но как именно оно это делает не имеет значения. При изменении приложения, интерфейс остаётся прежним, и клиентам не нужно подстраиваться.
А API, который предоставляют RESTful WEB-сервисы, называется RESTful API.
REST — не протокол, а, так называемый, стиль архитектуры (один из). Развиваемому вместе с HTTP Роем Филдингом, REST’у было предназначено использовать HTTP 1.1, в качестве транспорта.
Адрес назначения (или иным словом — объект, или ещё иным — эндпоинт) — это привычный нам URI.
Формат передаваемых данных — XML или JSON.
Для этой серии статей на linkmeup развёрнута read-only (для вас, дорогие, читатели) инсталляция NetBox: netbox.linkmeup.ru:45127.
На чтение права не требуются, но если хочется попробовать читать с токеном, то можно воспользоваться этим: API Token: 90a22967d0bc4bdcd8ca47ec490bbf0b0cb2d9c8.
Давайте интереса ради сделаем один запрос:
То есть утилитой curl мы делаем GET объекта по адресу netbox.linkmeup.ru:45127/api/dcim/devices/1/ с ответом в формате JSON и отступом в 4 пробела.
Или чуть более академически: GET возвращает типизированный объект devices, являющийся параметром объекта DCIM.
Этот запрос можете выполнить и вы — просто скопируйте себе в терминал.
Вот что мы получим в ответ:
Это JSON (как мы и просили), описывающий device с ID 1: как называется, с какой ролью, какой модели, где стоит итд.
Так будет выглядеть HTTP-запрос:
Так будет выглядеть ответ:
А теперь разберёмся, что же мы натворили.
Структура сообщений HTTP
HTTP-сообщение состоит из трёх частей, только первая из которых является обязательной.
- Стартовая строка
- Заголовки
- Тело сообщения
Стартовая строка
Стартовые строки HTTP-запроса и ответа выглядят по-разному.
HTTP-Запрос
HTTP-Ответ
Заголовки
В заголовках передаются параметры данной HTTP-транзакции.
Например, в примере выше в HTTP-запросе это были:
В них указано, что
- Обращаемся к хосту netbox.linkmeup.ru:45127,
- Запрос был сгенерирован в curl,
- А принимаем данные в формате JSON с отступом 4.
В них указано, что
- Тип сервера: nginx на Ubuntu,
- Время формирования ответа,
- Формат данных в ответе: JSON
- Длина данных в ответе: 1638 байтов
- Соединение не нужно закрывать — ещё будут данные.
Тело HTTP-сообщения
Тело используется для передачи собственно данных.
В HTTP-ответе это может быть HTML-страничка, или в нашем случае JSON-объект.
Между заголовками и телом должна быть как минимум одна пустая строка.
При использовании метода GET в HTTP-запросе обычно никакого тела нет, потому что передавать нечего. Но тело есть в HTTP-ответе.
А вот например, при POST уже и в запросе будет тело. Давайте о методах и поговорим теперь.
Методы
Как вы уже поняли, для работы с WEB-сервисами HTTP использует методы. То же самое касается и RESTful API.
Возможные сценарии в реальной жизни описываются термином CRUD — Create, Read, Update, Delete.
Вот список наиболее популярных методов HTTP, реализующих CRUD:- HTTP GET
- HTTP POST
- HTTP PUT
- HTTP DELETE
- HTTP PATCH
Давайте на примере NetBox разберёмся с каждым из них.
HTTP GET
Это метод для получения информации.
Так, например, мы забираем список устройств:
Метод GET безопасный (safe), поскольку не меняет данные, а только запрашивает.
Он идемпотентный с той точки зрения, что один и тот же запрос всегда возвращает одинаковый результат (до тех пор, пока сами данные не поменялись).
На GET сервер возвращает сообщение с HTTP-кодом и телом ответа (response code и response body).
То есть если всё OK, то код ответа — 200 (OK).
Если URL не найден — 404 (NOT FOUND).
Если что-то не так с самим сервером или компонентами, это может быть 500 (SERVER ERROR) или 502 (BAD GATEWAY).
Все возможные коды ответов.Тело возвращается в формате JSON или XML.
Давайте ещё пару примеров. Теперь мы запросим информацию по конкретному устройству по его имени.
Здесь, чтобы задать условия поиска в URI я ещё указал атритбут объекта (параметр name и его значение mlg-leaf-0). Как вы можете видеть, перед условием и после слэша идёт знак «?», а имя и значение разделяются знаком » bash»> GET /api/dcim/devices/?name=mlg-leaf-0 HTTP/1.1 Host: netbox.linkmeup.ru:45127 User-Agent: curl/7.54.0 Accept: application/json; indent=4
Если нужно задать пару условий, то запрос будет выглядеть так:
Здесь мы запросили все устройства с ролью leaf, расположенные на сайте mlg.
То есть два условия отделяются друг от друга знаком «&».Из любопытного и приятного — если через «&» задать два условия с одним именем, то между ними будет на самом деле не логическое «И», а логическое «ИЛИ».
То есть вот такой запрос и в самом деле вернёт два объекта: mlg-leaf-0 и mlg-spine-0
Попробуем обратиться к несуществующему URL.
HTTP POST
POST используется для создания нового объекта в наборе объектов. Или более сложным языком: для создания нового подчинённого ресурса.
То есть, если есть набор devices, то POST позволяет создать новый объект device внутри devices.
Выберем тот же Endpoint и с помощью POST создадим новое устройство.
Здесь уже появляется заголовок Authorization, содержащий токен, который авторизует запрос на запись, а после директивы -d расположен JSON с параметрами создаваемого устройства:
В ответ приходит HTTP-ответ с кодом 201 (CREATED) и JSON’ом в теле сообщения, где сервер возвращает все параметры о созданном устройстве.
Теперь новым запросом с методом GET можно его увидеть в выдаче:
POST, очевидно, не является ни безопасным, ни идемпотентным — он наверняка меняет данные, и дважды выполненный запрос приведёт или к созданию второго такого же объекта, или к ошибке.
HTTP PUT
Это метод для изменения существующего объекта. Endpoint для PUT выглядит иначе, чем для POST — в нём теперь содержится конкретный объект.
PUT может возвращать коды 201 или 200.
Важный момент с этим методом: нужно передавать все обязательные атрибуты, поскольку PUT замещает собой старый объект.
Поэтому, если например, просто попытаться добавить атрибут asset_tag нашему новому устройству, то получим ошибку:
Но если добавить недостающие поля, то всё сработает:
HTTP PATCH
Этот метод используется для частичного изменения ресурса.
WAT? Спросите вы, а как же PUT?PUT — изначально существовавший в стандарте метод, предполагающий полную замену изменяемого объекта. Соответственно в методе PUT, как я и писал выше, придётся указать даже те атрибуты объекта, которые не меняются.
А PATCH был добавлен позже и позволяет указать только те атрибуты, которые действительно меняются.
Здесь также в URL указан ID устройства, но для изменения только один атрибут serial.
HTTP DELETE
Очевидно, удаляет объект.
Метод DELETE идемпотентен с той точки зрения, что повторно выполненный запрос уже ничего не меняет в списке ресурсов (но вернёт код 404 (NOT FOUND).
Способы работы с RESTful API
Curl — это, конечно, очень удобно для доблестных воинов CLI, но есть инструменты получше.
Postman
Postman позволяет в графическом интерфейсе формировать запросы, выбирая методы, заголовки, тело, и отображает результат в удобочитаемом виде.
Кроме того запросы и URI можно сохранять и возвращаться к ним позже.
Так мы можем сделать GET:
Здесь указан Token в GET только для примера.
Postman служит только для работы с RESTful API.
Один из приятных бонусов специфицированного API в том, что вы можете в Postman импортировать все эндпоинты и их методы как коллекцию.
Для этого в окне Import (File->Import) выберите Import From Link и вставьте в окно URL netbox.linkmeup.ru:45127/api/docs/?format=openapi.
Далее, всё, что только можно, вы найдёте в коллекциях.
Python+requests
Но даже через Postman вы, скорее всего, не будете управлять своими Production-системами. Наверняка, у вас будут внешние приложения, которые захотят без вашего участия взаимодействовать с ними.
Например, система генерации конфигурации захочет забрать список IP-интерфейсов из NetBox.
В Python есть чудесная библиотека requests, которая реализует работу через HTTP.
Пример запроса списка всех устройств:Снова добавим новое устройство:
Python+NetBox SDK
В случае NetBox есть также Python SDK — Pynetbox, который представляет все Endpoint’ы NetBox в виде объекта и его атрибутов, делая за вас всю грязную работу по формированию URI и парсингу ответа, хотя и не бесплатно, конечно.
Например, сделаем то же, что и выше, использую pynetbox.
Список всех устройств:Добавить новое устройство:
SWAGGER
За что ещё стоит поблагодарить ушедшее десятилетие, так это за спецификации API. Если вы перейдёте по этому пути, то попадёте в Swagger UI — документацию по API Netbox.
На этой странице перечислены все Endpoint’ы, методы работы с ними, возможные параметры и атрибуты и указано, какие из них обязательны. Кроме того описаны ожидаемые ответы.
На этой же странице можно выполнять интерактивные запросы, кликнув на Try it out.
При нажатии на Execute Swagger UI сформирует строку curl, с помощью которой можно аналогичный запрос сделать из командной строки.
В Swagger UI можно даже создать объект:
Для этого достаточно быть авторизованным пользователем, обладающим нужными правами.
То, что мы видим на этой странице — это Swagger UI — документация, сгенерированная на основе спецификации API.
С трендами на микросервисную архитектуру всё более важным становится иметь стандартизированный API для взаимодействия между компонентами, эндпоинты и методы которого легко определить как человеку, так и приложению, не роясь в исходном коде или PDF-документации.
Поэтому разработчики сегодня всё чаще следуют парадигме API First, когда сначала задумываются об API, а уже потом о реализации.
В этом дизайне сначала специфицируется API, а затем из него генерируются документация, клиентское приложение, серверная часть и необходимы тесты.Swagger — это фреймворк и язык спецификации (который ныне переименован в OpenAPI 2.0), позволяющие реализовать эту задачу.
Углубляться в него я не буду.За бо́льшими деталями сюда:
Критика REST и альтернативы
Существует и такая, да. Не всё в том мире 2000-го года так уже радужно.
Не являясь экспертом, не берусь предметно раскрывать вопрос, но дам ссылку на небесспорную статью на Хабре.
Альтернативным интерфейсом взаимодействия компонентов системы сегодня является gRPC. Ему же пророчат большое будущее на ниве новых подходов к работе с сетевым оборудованием. Но о нём мы поговорим когда-то в будущем, когда придёт его черёд.
Можно также взглянуть на многообещающий GraphQL, но нам опять же нет нужды с ним работать пока, поэтому остаётся на самостоятельное изучение.
Важно
Токен a9aae70d65c928a554f9a038b9d4703a1583594f был использован только в демонстрационных целях и больше не работает.Прямое указание токенов в коде программы недопустимо и сделано здесь мной только в интересах упрощения примеров.
Алгоритм CRUD
Программирование и разработка
API должен выполнять четыре типа функций. Он должен иметь возможность создавать новые данные, а также читать, обновлять и удалять существующие. В информатике мы называем эти параметры CRUD.
Метод CRUD необходим при создании веб-приложений, поскольку он позволяет структурировать модели, которые вы создаёте для своих API. Но как работает CRUD? Как вы взаимодействуете с API с помощью CRUD?
В этой статье мы отвечаем на эти вопросы. Мы начнём с обсуждения основ CRUD, а затем рассмотрим несколько примеров того, как взаимодействовать с API с помощью CRUD.
Зачем нам нужен CRUD
Допустим, мы создаём API, в котором хранится кофе, продаваемый в нашем кафе. Этот API должен иметь возможность хранить различные объекты кофе. Кофейный объект может включать:
- Уникальный идентификатор кофе.
- Название кофе.
- Цена на кофе.
Мы хотим убедиться, что пользователи могут взаимодействовать и изменять данные, хранящиеся в нашем API. Вот почему нам нужно следовать структуре CRUD. В конце концов, для чего нужен API, в котором хранится кофе, если компания не может изменить цену на свой кофе? Зачем компании использовать API, который не позволяет удалять записи?
Что такое CRUD
CRUD — это аббревиатура от Create, Read, Update и Delete.
Когда вы работаете с веб-службами, CRUD соответствует следующим HTTP-методам, которые используются, чтобы сообщить веб-серверу, как вы хотите взаимодействовать с веб-сайтом:
- Создать: POST.
- Читать: GET.
- Обновление: PUT.
- Удалить: DELETE.
Давайте рассмотрим каждого в отдельности.
Мы собираемся использовать утилиту командной строки cURL для создания примеров запросов к API кофе, чтобы вы могли увидеть, как работают эти операции. Прежде чем мы начнём, запустите следующую команду в терминале на вашем компьютере, чтобы убедиться, что cURL установлен:
Если в вашем терминале появляется ошибка «curl: command not found», вам необходимо установить cURL. В противном случае вы готовы приступить к работе!
Создать
API, который хранит данные для нашего кафе, должен позволить нам добавлять новые записи в меню. В этом случае мы сможем создать новый кофейный элемент, указав его название и цену.
Чтобы добавить новый кофе в меню, мы можем использовать запрос POST, который позволяет нам отправлять данные в наш API, которые будут храниться в базе данных.
Вот информация о кофейном элементе, который мы хотим добавить:
- Название: Эспрессо
- Стоимость: 1.95
Следующая команда cURL позволяет нам создать кофе с этими деталями с помощью нашего API:
curl -X POST http: // localhost: 5000 / add -d name = Espresso -d price = 1.95
В этой команде мы используем флаг -X, чтобы структурировать наш запрос как запрос POST. Затем мы используем флаги -d, чтобы указать данные, которые мы хотим отправить в наш API. В этом случае мы используем два флага -d: один для указания названия кофе, а другой для указания его цены. Наш код возвращает:
Эта команда создаёт новый кофе в нашей базе данных с именем «Эспрессо» и ценой «1,95».
Читать
Наш API должен позволять нам видеть список всех сортов кофе в нашем меню. Чтобы увидеть эти данные, мы можем использовать запрос GET. Это позволяет нам видеть список кофе в нашем меню, не внося изменений в данные, хранящиеся в нашем API.
Эта команда позволяет нам получить список кофе из нашего API:
curl -X GET http: // localhost: 5000 / coffees
Наша команда возвращает:
Как видите, этот ресурс позволяет нам получить список кофе. API, использующий структуру CRUD, часто также позволяет получать отдельные записи. Например, следующая команда позволяет нам получить данные об одном элементе кофе:
curl -X GET http: // localhost: 5000 / coffees / 1
Наш код возвращает:
Вы можете видеть, что наша команда вернула кофе, идентификатор которого равен 1. В данные не было внесено никаких изменений, потому что запросы GET могут получать данные только из API.
Обновить
Нам также необходимо поддерживать обновление записей в нашем API. Соответствующий HTTP-метод для обновления ресурса с помощью CRUD — PUT.
Если мы хотим изменить цену нашего латте на 2,75 доллара, мы можем использовать следующий запрос PUT:
curl -X PUT http: // localhost: 5000 / update / 2 -d name = Latte -d price = 2.75
Наш код возвращает:
Этот запрос изменяет имя и цену записи Latte на значения, которые мы указали в нашей команде cURL.
Удалять
Последняя операция в структуре CRUD — это Delete, чей соответствующий HTTP-метод — DELETE.
Предположим, у нас закончился порошок эспрессо, и мы должны удалить его из нашего меню. Мы могли бы сделать это, используя следующий запрос:
curl -X DELETE http: // localhost: 5000 / DELETE / 1
Когда мы запускаем этот код, ответ не возвращается. Это потому, что указанный кофе удалён с нашего сервера. Если мы запустим запрос GET, чтобы снова увидеть список кофе, мы увидим, что запись со значением 1 — эспрессо — была удалена.
Теперь вы знаете основы. CRUD — это структура, которая определяет четыре основные операции, которые должна выполнять веб-служба. Чтобы углубить свои знания о CRUD, подумайте о гипотетическом API, который вы можете спроектировать и составить список маршрутов.
Например, API для отслеживания ваших любимых песен может иметь следующие маршруты:
- /songs (GET)
- /songs/new (POST)
- /songs/:id (GET)
- /songs/:id (PUT)
- /songs/:id (DELETE)
Попробуйте составить список маршрутов для вашего собственного API и запишите соответствующие методы HTTP.
Если вы хотите поиграть с веб-запросами, которые мы использовали в этом руководстве, вы можете просмотреть код, который мы использовали для размещения API на GitHub.
chsakell's Blog
WEB APPLICATION DEVELOPMENT TUTORIALS WITH OPEN-SOURCE PROJECTS
Home › ASP.NET › Web API basic CRUD Operations following HTTP principles
Web API basic CRUD Operations following HTTP principles
Web API makes building HTTP Services quite easy and pleasant since most of the hard work is taking place under it’s Framework’s umbrella. For example, when a client application makes a call to a Web API client, Web API can figure out by itself, what type of data passed to it and what type of data is expected to be returned. This transparency though, doesn’t mean that you don’t need to be aware of the basic HTTP Restful principles. We have seen in previous post the basics for starting with Web API but we weren’t so absolute as far as for the HTTP principles. This post will show you the right way to build HTTP Services with Web API. We will create a solution to support all CRUD operations Create – Read – Update – Delete on in-memory data. Let’s begin.
Create an ASP.NET 4 Web Application project, named HttpPrinciplesWithWebAPI selecting the Web API template. Delete the “ValuesController” inside the controllers folder and in it’s position create a new one named GroupController selecting the Empty API controller template. This controller will allow us to get Person objects from a group, add/delete a person to/from a group and lastly, update a group’s Person object. We need to create a Person class so paste the following code inside the class you created.
Let’s create our first Web API action method, the Get() one. We need some mock data so we will create a static variable of Person objects.
We used the HTTP convention, that is we named our action method with a HTTP GET prefix. You could give it any name you wanted but you would have to annotate your method with a HttpGet attribute. Build your application and run it. Add a /api/group/ to the default url and make sure your Web API is on air.
If you can, test your Web API service through Fiddler too. This tool can provide you with important information about your HTTP Services.
Before start getting interesting in HTTP principles let’s change a little bit our Default View (the page is loaded when you start your application). Change Index.cshtml file under /Views/Home folder as follow.
We deleted the most of the default content existed and add a simple ul element that each time you run your application, it is filled through an Ajax GET request to your Get Web API action method. Build and start your application.
Ok, it’s time to get some serious. Add the following Get(int Id) action method to your GroupController.
This method will return a specific Person object according to Id value passed. You can see that I highlighted line 7. I made this for a reason. You should know that when you send an HTTP request to get a resource (e.g a specific Person), if that resource doesn’t exist, you should get back a 404 code telling you that the item you requested doesn’t exist. This is an HTTP principle. By default though this isn’t supported. Let’s test it. Request from Fiddler a valid Person and then an invalid. Check the code and value returned in the second case.
Request an invalid Person object, for example a person with >
Instead of returing a null value and Status OK, let’s return a 404 code and a message telling that the Person object requested doesn’t exist. Change the Get(int Id) action method as follow.
The message you must return must be of type HttpResponseMessage. If resource not found you create an message of that type using the Request.CreateErrorResponse function, passing as parameters a 404 code HttpStatusCode.NotFound and a custom message. If resource is found, you create a HttpResponseMessage message using the Request.CreateResponse function with HttpStatusCode.OK . Build your application and test the previous scenario again. Check the difference.
Let’s keep going. Same story with the POST action methods. Add a POST action to your GroupController in order to add a Person object to the in memory mock Person list, Group .
The [FromBody] attribute means that new object’s value will come from the body. It could come for example from the query string. To post a Person object through Fiddler (we are going to see how you can post from your pages in other post), in the composer tab, select POST, in the Requested Headers add a Content- Type: application/json element and lastly, put the json value into the Requested Body. Finally press execute.
To return a 201 code telling that your resource was created, change your POST method as follow.
The only line I want to explain is the 6th. The msg.Headers.Location = new Uri(Request.RequestUri + “/” + p.Id.ToString()); will tell that new resource’s location will match the requested URL (when you sent the POST request, plus a /Id. In other words, we set the header location to listen the Get(int Id) Web API action method. Build and run your application. Check from Fiddler that a 201 Request Created Code is returned when you sent a valid POST request.
Well, this is pretty much the most important you need to know for HTTP GET and POST requests. One last thing I wanna show you, is how to sent xml POST requests. You may think that you setting the Content-Type: application/xml will be enough but that’s wrong. You need to give some more information about the XML object you want to POST. Check the follow image and you will understand.
That’s all for now. More interesting things on Web API coming on next posts so keep in touch. I hope you enjoyed the post. Download the project we created from here.