Пример json api php

В данной статье вы узнаете, как создать простой REST API в PHP.

1. Обзор проекта

1.1 Что такое REST API?

REST API позволяет вашему приложению взаимодействовать с одним или несколькими различными приложениями, используя концепции REST.

1.2 Зачем нужен REST API?

Во многих приложениях REST API необходим, потому что это самый легкий способ создания, чтения, обновления или удаления информации между различными приложениями через Интернет или протокол HTTP. Эта информация представляется пользователю в одно мгновение, особенно если вы используете JavaScript для отображения данных на веб-странице.

1.3 Где используется REST API?

REST API может использоваться любым приложением, которое может подключаться к Интернету. Если данные из приложения могут быть созданы, прочитаны, обновлены или удалены с помощью другого приложения, это обычно означает, что используется REST API.

2. Файловая структура

3. Настройка базы данных

3.1 Создание таблицы категорий

3.2 Дамп данных для таблицы категорий

3.3 Создание таблицы товаров

3.4 Дамп данных для таблицы товаров

3.5 Подключение к базе данных

Приведенный ниже код показывает учетные данные базы данных и метод для получения подключения к базе данных с помощью PDO.

Создайте папку api и откройте её. Создайте папку config и в ней создайте файл database.php со следующим кодом.

4. Получение товаров

4.1 Создание объекта Product

Код ниже содержит класс с именем Product и несколько свойств. Также показан метод конструктора, который принимает соединение с базой данных.

4.2 Создание файла для чтения товаров

Код ниже содержит заголовки о том, кто может читать этот файл и какой тип содержимого он будет возвращать.

4.3 Подключение к базе данных и таблице товаров

Замените комментарий // подключение к базе данных будет здесь в файле read.php следующим кодом.

4.4 Чтение товаров из базы данных

Замените комментарий // чтение товаров будет здесь в файле read.php следующим кодом.

4.5 Создание метода read()

4.6 Уведомление пользователя о том, что товары не найдены

Замените комментарий // ‘товары не найдены’ будет здесь в файле read.php следующим кодом.

5. Создание товаров

5.1 Создание файла create.php

Откройте папку product и создайте в ней файл create.php со следующим содержимым.

5.2 Создание метода create()

6. Получение одного товара

6.1 Создание файла read_one.php

6.2 Создание метода readOne()

7. Обновление товара

7.1 Создание файла update.php

7.2 Создание метода update()

8. Удаление товара

8.1 Создание файла delete.php

Откройте папку product и создайте файл delete.php со следующим содержимым.

8.2 Создание метода delete()

9. Поиск товаров

9.1 Создание файла search.php

В папке product создайте файл search.php со следующим кодом.

9.2 Создание метода search()

10. Пагинация товаров

10.1 Создание файла read_paging.php

В папке product создайте файл read_paging.php со следующим кодом.

10.2 Создание файла core.php

Этот файл содержит нашу базовую конфигурацию, такую как базовый URL и переменные пагинации.

Откройте папку config и создайте в ней файл core.php со следующим содержимым.

10.3 Создание метода readPaging()

10.4 Создание метода count()

Так же в классе Product (файл product.php) добавьте метод count() для создания массива пагинации.

10.5 Получение массива пагинации

11. Получение категорий

11.1 Создание объекта Category

Откройте папку objects и создайте новый файл category.php со следующим кодом.

11.2 Создание файла read.php

Создайте новую папку category в корне, и в ней файл read.php со следующим кодом.

11.3 Создание метода read()

Если вам понравилась данная статья, рекомендую к прочтению создание регистрации и авторизации в php с использованием JWT.

Надеюсь, вам понравилась данная информация. Если вам интересна тема web-разработки, то можете следить за выходом новых статей в Telegram.

Источник

Принципы построения REST JSON API

Эта памятка писалась для внутренних нужд (открыть глаза менее опытным в вебе коллегам). Но, т.к. я насмотрелся велосипедов от довольно уважаемых, казалось бы, контор, — выкладываю на хабр. Мне кажется, многим будет полезно.

Зачем

Надеюсь, читающий уже понимает, зачем ему вообще нужен именно REST api, а не какой-нибудь монстр типа SOAP. Вопрос в том, зачем соблюдать какие-то стандарты и практики, если браузеры вроде бы позволяют делать что хочешь.

Структура запросов и ответов

Любой http-запрос начинается со строки

где METHOD — это метод доступа (GET, PUT и т.д.), а URI — адрес запрашиваемого ресурса.

В начале запроса идут заголовки — просто текстовые строки вида key: value
Затем передаётся пустая строка, означающая конец секции заголовков, и затем — тело запроса, если оно есть.

В ответе сначала передаётся строка с версией http, кодом и строковым статусом ответа (например HTTP/1.1 200 OK ), далее текстовые заголовки ответа, потом пустая строка, потом тело ответа.

Тут вроде всё просто.

Кодирование запросов и ответов

Кодировка для всех и запросов, и ответов — UTF-8 и только UTF-8, т.к. некоторые, кхм, «браузеры» имеют привычку игнорировать содержимое заголовка charset.

Использование кодов символов и html-сущностей не допускается, т.е. режим JSON_UNESCAPED_UNICODE обязателен. Не все клиенты знают всю таблицу html сущностей (типа каких-нибудь ù ), да и при чём тут html. Не все клиенты готовы/хотят заниматься перекодированием \uXXXX; и &#XX;. Плюс возможны «весёлые» ситуации с избыточным экранированием или пропаданием слэшей и амперсандов.

Все данные, кроме URI и двоичных файлов, передаются в формате JSON. Обратите внимание, что далеко не всякий валидный javascript код является валидным JSON.
В частности, для строк используются только двойные кавычки. Одинарные кавычки в json-данных, хотя и допустимы в «обычном» javascript, могут вызвать непредсказуемые плохо отлавливаемые баги.

В запросах обязательно указывается заголовок

Вызовы к API отличаются от прочих вызовов (например, обычной загрузки html страницы по данному URI) именно по наличию application/json в Accept.

В ответах 2хх с непустым телом обязательно наличие заголовка ответа

При наличии тела запроса также обязателен заголовок запроса

либо, при загрузке файлов,

и далее, в первой части

после чего для каждого файла

Если вы используете защиту от CSRF (а лучше бы вам её использовать), то удобнее передавать CSRF-токен в отдельном заголовке (типа X-CSRF-Token) для всех запросов, а не внедрять вручную в каждый запрос. Хранить CSRF токен в куках плохо по той причине, что куки можно украсть, в чём собственно и состоит суть CSRF атаки.

Структура URI

Нагородить можно всякое, но лучшая практика — чтобы все URI имели вид

ну, или если у вас api лежит в какой-то папке,

Для разбора части URI до знака вопроса можно использовать регулярку

Ведущий слэш обязателен, т.к. неизвестно, с какого URL будет осуществлён запрос.

Методы HTTP

GET /:entity/:id — getById

В случае успеха сервер возвращает 200 OK с полями объекта в формате JSON в теле ответа (без дополнительного оборачивания в какой-либо объект)

В случае, если объект с такими id не существует, сервер возвращает 404 Not Found

В ответе обязательно должны быть заголовки, касающиеся политики кэширования, т.к. браузеры активно кешируют GET и HEAD запросы. При остутствии какой-либо политики управления кэшем должно быть:

GET /:entity[?param1=. &param2=. ] — списочный get

Простой случай: в случае успеха сервер возвращает 200 OK с массивом объектов в формате JSON в теле ответа (т.е. ответ начинается с [ и заканчивается ] ).

Если массив получился пустой, всё равно вовзращается 200 OK с пустым масивом [] в теле ответа.

Более сложный вариант: возвращается объект, в одном из полей которого — искомый массив. В остальных полях — данные о пагинации, фильтры, счётчики и пр. Только держите это консистентным по всем api.

HEAD /:entity[/:id] — запрос заголовков

Полный аналог GET с таким же URI, но не возвращает тело ответа, а только HTTP-заголовки.

Реализация поддержки HEAD запросов веб-сервером обязательна.

Активно используется браузерами в качестве автоматических pre-flight запросов перед выполнением потенциально опасных, по их мнению, операций. Например, браузер Chrome активно кидается head-запросами для получения политик CORS при кросс-доменных операциях (виджеты и пр). При этом ошибка обработки такого head-запроса приведёт к тому, что основной запрос вообще не будет выполнен браузером.

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

POST /:entity — создаёт новый объект типа :entity

В теле запроса должны быть перечислены поля объекта в формате JSON без дополнительного заворачивания, т.е.

В случае успеха сервер должен возвращать 201 Created с пустым телом, но с дополнительным заголовком

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

Возвращать тело ответа чаще всего не требуется, так как у клиента есть все необходимые данные, а id созданного объекта он может получить из Location.

Также метод POST используется для удалённого вызова процедур (RPC), в этом случае ответ будет иметь статус 200 OK и результаты в теле. Вообще смешивать REST и RPC в одном api — идея сомнительная, но всякое бывает.

Единственный неидемпотентный некешируемый метод, т.е. повтор двух одинаковых POST запросов создаст два одинаковых объекта.

PUT /:entity/:id — изменяет объект целиком

В запросе должны содержаться все поля изменяемого объекта в формате JSON.

В случае успеха должен возвращать 204 No Data с пустым телом, т.к. у клиента есть все необходимые данные.

Идемпотентный запрос, т.е. повторный PUT с таким же телом не приводит к каким-либо изменениям в БД.

PATCH /:entity/:id — изменяет отдельные поля объекта

В запросе должны быть перечислены только поля, подлежащие изменению.

В случае успеха возвращает 200 OK с телом, аналогичным запросу getById, со всеми полями изменённого объекта.

Используется с осторожностью, т.к. два параллельных PATCH от двух разных клиентов могут привести объект в невалидное состояние.

DELETE /:entity/:id — удаляет объект, если он существует.

В случае успеха возвращает 204 No Data с пустым телом, т.к. возвращать уже нечего.

Идемпотентный запрос, т.е. повторный DELETE с таким же адресом не приводит к ошибке 404.

OPTIONS /:entity[/:id]

Получает список методов, доступных по данному URI.

Сервер должен ответить 200 OK с дополнительным заголовком

Некешиуремый необязательный метод.

Обработка ошибок

Возвращаемые ошибки передаются с сервера на клиент как ответы со статусами 4хх (ошибка клиента) или 5хх (ошибка сервера). При этом описание ошибки, если оно есть, приводится в теле ответа в формате text/plain (без всякого JSON). Соответственно, передаётся заголовок ответа

Использовать html для оформления сообщений об ошибках в api — так себе идея, будут проблемы журналированием и т.д. Предполагается, что клиент способен сам красиво оформить сообщение об ошибке для пользователя.

При выборе конкретных кодов ошибок не следует слишком увлекаться и пытаться применить существующие коды только потому, что название кажется подходящим. У многих кодов есть дополнительные требования к наличию определённых заголовков и специальная обработка браузерами. Например, код 401 запускает HTTP-аутентификацию, которая будет странно смотреться в каком-нибудь приложении на react или electron.

UPD по мотивам комментариев. Клиенты у вас будут разные: не только веб и мобильные приложения, но и такие штуки, как запускалка интеграционных тестов (CI), балансировщик нагрузки или система мониторинга у админов. Использование или неиспользование того или иного статуса ошибки определяется тем, будет ли он полезен хоть какому-то клиенту (т.е. этот клиент сможет предпринять какие-то действия конкретно по этому коду) и, наоборот, не будет ли проблем у какого-то из клиентов из-за неиспользования вами этого кода. Придумать реальный use-case, когда реакция клиента будет различаться в зависимости от 404 или 410, довольно сложно. При этом отличий 404 от 200 или 500 — вагон и телега.

400 Bad Request

Универсальный код ошибки, если серверу непонятен запрос от клиента.

403 Forbidden

Возвращается, если операция запрещена для текущего пользователя. Если у оператора есть учётка с более высокими правами, он должен перелогиниться самостоятельно. См. также 419

404 Not Found

Возвращается, если в запросе был указан неизвестный entity или id несуществующего объекта.

Списочные методы get не должны возвращать этот код при верном entity (см. выше).

Если запрос вообще не удалось разобрать, следует возвращать 418.

415 Unsupported Media Type

Возвращается при загрузке файлов на сервер, если фактический формат переданного файла не поддерживается. Также может возвращаться, если не удалось распарсить JSON запроса, или сам запрос пришёл не в формате JSON.

418 I’m a Teapot

Возвращается для неизвестных серверу запросов, которые не удалось даже разобрать. Обычно это указывает на ошибку в клиенте, типа ошибки при формировании URI, либо что версии протокола клиента и сервера не совпадают.

419 Authentication Timeout

Отправляется, если клиенту нужно пройти повторную авторизацию (например, протухли куки или CSRF токены). При этом на клиенте могут быть несохранённые данные, которые будут потеряны, если просто выкинуть клиента на страницу авторизации.

422 Unprocessable Entity

Запрос корректно разобран, но содержание запроса не прошло серверную валидацию.

Например, в теле запроса были указаны неизвестные серверу поля, или не были указаны обязательные, или с содержимым полей что-то не так.

Обычно это означает ошибку в введённых пользователем данных, но может также быть вызвано ошибкой на клиенте или несовпадением версий.

500 Internal Server Error

Возвращается, если на сервере вылетело необработанное исключение или произошла другая необработанная ошибка времени исполнения.

Всё, что может сделать клиент в этом случае — это уведомить пользователя и сделать console.error(err) для более продвинутых товарищей (админов, разработчиков и тестировщиков).

501 Not Implemented

Возвращается, если текущий метод неприменим (не реализован) к объекту запроса.

Ну вот, в общем-то, и всё. Спасибо за внимание!

Источник

JSON API Мой Склад, самообучение

START UPDATE 2019-11-18
Заметил, что статья до сих пор для кого то служит источником информации.
Я сделал рефакторинг что бы сделать код более прямолинейным. По пути поправил пару досадных багов.
FINISH UPDATE 2019-11-18

Есть такой способ самообучения — как выполнение тестовых заданий. Его преимущество в том что объём задания конечен, сроки ограничены. Это не позволяет тянуть резину до бесконечности или самозабвенно вырисовывать завихрения и завитушки архитектурных изысков.

Приятный бонус такой тренировки скиллов заключается в знакомстве с новыми технологиями и бизнес процессами, которое кроме всего прочего востребованы в реальных задачах.

На этот раз надо было сделать страничку для формирования заказа покупателя в сервисе «Мой склад». Для меня это как полёт на Луну: в веб разработке я чуть меньше чем новичок, с фронтэндом знаком только по наслышке, а тут целую страницу надо разработать, ох ты Йожик!
Любая критика и советы приветствуются.

В коментах очень много ругательств, моё решение настолько ужасно, что для него сделали рефакторинг во что то приличное:
michael_vostrikov

От нечего делать сделал небольшой рефакторинг этого задания (хотя там много чего еще можно поменять), не столько для вас, сколько для тех, кто потом найдет в поиске эту статью:
коммиты, разметка, отправка формы.

Поехали!

Первым делом конечно гуглить, нагуглилась только ссылка на документацию, туториалов, примеров — ноль.

Ещё нагуглилось: «JSON API доступен для подписчиков на всех тарифах, кроме Бесплатного» уупс! Платного мне конечно ни кто не дал, покупать не камильфо, но я подумал что если дали такое задание, то наверное на Бесплатном что то там функционирует и продолжил работу.

И конечно нагуглилось «moysklad-client — npm — JavaScript клиент для комфортной работы с API сервиса МойСклад», но я с JS исключительно на «Вы», и по условиям задания, написать надо на PHP. Так что даже разбираться не стал, что там на JS можно делать.

Первое

Первое что надо сделать, это познакомиться с документацией. Познакомился.
Второе — составить план. Составил.
План, начало.
Действие первое — авторизация.
Действие второе — показать список Номенклатур.
Действие третье — добавить Заказ покупателя.
Действие четвёртое — добавить Позиции в Заказ покупателя.
Цель достигнута, конец плана.

Авторизация

Я видел код в котором для общения с API использовался cUrl. Я не знаю что такое cUrl, я не знаю как принято общаться с API, но если есть код который можно скопипастить, то проверить его пригодность не сложно. Скопировал вставил, обработал напильником — получилось.

Не буду утомлять вас интимными подробностями о дружбе напильника с копипастой, вот работающий код:

Итак, это была инициализация объекта curl для обмена сообщениями с сервером API.

Чистая копипаста, не спрашивайте меня почему так.

Показать список Номенклатур

Одних номенклатур оказалось мало, для Заказа покупателя, надо указать юридическое лицо Поставщика и контрагента Покупателя. У владельца учётки «Мой склад» может быть несколько юридических лиц, контрагентов — ясно понятно 100500, но конкретный Заказ покупателя, это заказ конкретного Контрагента в адрес конкретного Юридического лица.

Поэтому с номенклатурами обождём, займёмся сторонами «договора» — сделки.

Извиняюсь за ужасные названия констант, но мне с такими спокойней, точно ни с чем не перепутаю. Да я знаю что у case (switch) есть ветка default, но мне спокойней вбетонировать в код значение по умолчанию и не надеяться на превратности судьбы с case.

У каждой команды API свой адрес и свой метод, setCurl — устанавливает адрес и метод.

После этого методом getJuridicalPerson исполняем curl, получаем ответ в JSON, из ответа забираем только массив ‘rows’. Получили, сохранили, отложили.

С Контрагентами поступаем аналогично: setCurl => getCounterparty, Номенклатуры по тому же алгоритму: setCurl => getNomenclature.

Если бы это было не тестовое на два вечера после работы, а на два дня безработного специалиста, то можно было бы это автоматизировать, но это было тестовое в стиле — «лишь бы работало», поэтому я не стал изгаляться.

Для меня цель тестового была в том что бы пригубить и попробовать на вкус JSON API, рисовать красоту — цели не было.

Данные получили — это вообще не вопрос, дело дурацкое — дело не хитрое, интересней было как то это вывести на страничку, а потом со странички забрать, вот это была задачка.

Фронтэнд

Не знаю как правильно, я сделал так:

По клику на кнопку «Сформировать заказ покупателя», форма не отправляется — «return false;», но вызывается функция — «sendOrder();».

Источник

Примеры использования JSON-формата на PHP и JavaScript

Что такое JSON

Синтаксис JSON на примерах

Формат json обычно записывается в 2-х вариантах:

1. Последовательность значений. Например, последовательность 10, 15 и «test» в формате JSON будут выглядеть так:

Немного более сложный пример:

PHP функции для работы с JSON-форматом

В языке php начиная с версии 5.2. есть всего 4 функции:

В основном по-большей части, используются всего две функции: json_encode и json_decode. Не буду вдаваться в подробности их синтаксиса, подробнее можете посмотреть на php.net. Пример использования:

Обратите внимание : при кодировании в JSON-формат данных на русском языке, функция json_encode преобразует русские символы в юникод, т.е. заменяет их на \uXXXX и таким образом, json-строка становится не читабельной для человека (но понятной для браузера). Если нужно, чтобы преобразования в юникод не происходило (например, при отладке кода), можно просто использовать опцию JSON_UNESCAPED_UNICODE.

Так же, чтобы при кодировании не добавлялись слэши для экранирования и чтобы строки с числами кодировались как числа, можно использовать JSON_UNESCAPED_SLASHES и JSON_NUMERIC_CHECK. В итоге, чтобы json-строка была читабельной для человека, сделаем, например, так:

Без использования этих опций строка была бы такой:

а с использованием опций, получим читабельную строку:

Еще один момент: если нужно чтобы при декодировании json-строки функция json_decode возвращала именно массив, просто добавьте второй параметр в функцию равный true.

На этом рассмотрение php-функций завершу.

JavaScript функции для работы с JSON-форматом

Начнем с того, что JSON-формат, изначально был придуман для языка JavaScript и потом стал просто отдельным текстовым форматом, используемым в разных языках. Видимо, поэтому синтаксис JSON очень похож на синтаксис записи обычных объектов и массивов.

Функции JavaScript, используемые для преобразования в JSON-формат и обратно:

Простой пример декодирования json-строки в массив с цифрами:

Пример преобразования (сериализации) объекта в JSON-строку:

При сериализации (преобразовании) объекта в JSON-строку, вызывается метод toJSON этого объекта, если он существует. Если метода нет, тогда перечисляются все свойства объекта. Пример преобразования объекта с методом toJSON:

Обе функции JSON.parse и JSON.stringify имеют доп.параметры для уточнения правил преобразований. Не буду останавливаться на них в рамках этой статьи. Если необходимо, о них можно почитать, например, здесь: https://learn.javascript.ru/json.

Примеры практического применения JSON-формата

Собственно, лично я, применяю формат JSON в 2-х основных ситуациях:

1. Передача данных между браузером и сервером с использованием Ajax-запросов.

Например, у нас есть какая-то страница, на которой нужно обновить данные без перезагрузки страницы. Допустим, нужно чтобы с сервера «подгрузилась» информация со списком сотрудников и их данными.

В JavaScript с помощью jQuery делаем простой ajax-запрос к серверу и выводим данные в виде таблицы в браузер:

На сервере скрипт get-info.php к которому делается ajax-запрос, может быть, например, таким:

В этом примере JSON-строка, которая была передана с сервера в браузер была такой:

Я специально не стал показывать строку в виде «дерева», т.к. она передается именно в таком виде. И как вы можете оценить, запись данных в формате JSON получилась очень компактной, а это значит, что передача этих данных от сервера к браузеру будет практически мгновенной.

2. Запись сложных структур данных в базу данных.

Иногда бывают ситуации, когда заводить еще одну таблицу в базе данных не целесообразно, чтобы сохранить различные данные. Допустим, предположим, у зарегистрированного на сайте пользователя есть возможность сделать настройку цвета фона и цвета текста.

Вместо того, чтобы заводить еще одну таблицу ради 2-х настроек, можно просто в таблице со списком пользователей сделать текстовый столбец, в который помещать данные настроек пользователя. Тогда запрос обновления настроек, может например, быть таким:

В формате JSON, можно так же, например, записать в базу данных какие опции товаров выбрал покупатель.

Впринципе, можно даже и всё содержимое корзины записать в формате JSON, например, так:

В обычном не древовидном виде эта JSON-строка будет такой:

Таким образом, как видно из примеров, в формате JSON можно хранить и передавать практически любую информацию.

Источник

PHP и формат передачи данных JSON

JSON (JavaScript Object Notation) – формат для обмена данными в текстовом виде. Позволяющий передавать сложные структуры данных в сериализованном виде. Этот формат передачи данных стал настолько популярен, что уже в ядро PHP начиная с версии 5.2.0, были добавлены функции по обработке данных в этом формате. А это значит, что нет необходимости в подключении дополнительных расширений. Формат данных JSON хорошо понятен человеку. Кроме того данный тип обмена данными широко используется между различными API сервисами. А при корректной разработке алгоритмов для обмена информацией, можно получить очень высокий прирост скорости чем, к примеру, при работе с данными в формате XML.

Отправка данных

Отправить данные в формате JSON можно двумя способами: сформировать GET или POST запрос с закодированными данными расположенными в GET или POST переменной или же поместить данные в тело документа. На практике обычно используется второй вариант.

Для произведения отправки данных необходимы нижеперечисленные функции:

В качестве параметра value указываются данные которые требуется закодировать. Поддерживается любой тип кроме типа resource. Параметр options содержит битовую маску из возможных предоставленных значений (см. таблицу с предоставленными JSON константами).

Использование этой функции позволяет получить содержимое файла в виде строки. Параметр filename это имя считываемого файла. В параметре use_include_path начиная с версии PHP 5 можно использовать константу FILE_USE_INCLUDE_PATH для поиска файла в include path. Параметр context представляет ресурс контекста, созданный с помощью функции stream_context_create(). В случае неудавшейся попытки открытия файла, будет возвращено значение false. Параметр offset содержит смещение с которого начнется чтение данных. В параметре maxlen указывается размер получаемых данных.

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

Ниже приведен пример отправки данных в формате JSON:

Здесь используется импровизированная структура данных, состоящая из начальной и конечной даты, а также массива номеров некоторых условных записей. Обратите внимание на то, что в заголовке запроса Content-Type указывается тип “application/json”.

Получение данных

Для того чтобы получить переданные данные вышеописанным способом требуется произвести чтение данных из потока ввода “php://input”.

Используемые функции для принятия данных:

Ниже приведен пример получения данных в формате JSON на стороне сервера:

Полученная структура данных:

Примечание: необходимо учитывать тот момент, что для работы с форматом JSON, данные должны быть в кодировке utf-8.

Предоставленные JSON константы для функции json_encode()

Список возможных режимов для fopen() используя mode

Комментариев: 5

lavrik
30.04.2014 @ 10:37 дп

Источник