В чем заключается принцип построения взаимодействия beckend’а и frontend’a через JSON / REST api.
Что вообще такое “REST api” и “JSON api”?
Как я понимаю это 2 подхода к построению взаимодействию между beckend’ом и frontend’ом при котором принимаются соглашения что при запросе с frontend’a определенного типа выполняется соответственное действие на beckend’е.
Если у кого есть скиньте ссылки на обсуждение этого вопроса. Спасибо.
Сразу скажу что это мой взгляд на это, если ошибаюсь поправьте.
REST api - если коротко то это набор методов внутри протокола http для общения с сервером. (GET,POST,PUT и тд)
но что содержится в теле самого запроса, каждый выбирает что хочет, иногда это просто текст строка, иногда это данные в виде JSON, то есть объект преобразованный в строку, и опять же сам объект может быть организован как ему это угодно.
Так вот что бы каждый сам по себе не использовал REST api как ему вздумается, некоторые люди ограничиваются к примеру одним методом GET, не используя все остальное, то на помощь приходит JSON api. Это методология, согласно которой, вы должны генерировать запрос/ответ по определенным правилам. К примеру мы не можем удалять пользователя методом POST, а теперь мы должны использовать метод DELETE, поскольку сервер парсит наш запрос по обределенным правилам. Тоже самое касается тело ответа, оно дожно быть сформированно по определенным правилам, поскольку клиент, тоже парсит ответ сервера по определенным правилам, которые устанавливает JSON api стандарт, который в свою очередь, я напомню, использует RESTfull api.
Плюсы от этого, то что мы можем сразу работать с данными не замарачиваясь с их упаковкой и парсингом. И так как это стандарт, то другие разработчики придя в комманду уже будут знать как формировать запросы как на сервер так и обратно.
Надеюсь помог.
Как REST так и JSON api - это контракт, договор между клиентом и сервером о том как взаимодействовать друг с другом.
Контракт REST строится вокруг стандартных методов HTTP (GET, POST, PUT, DELETE) и схемы url. Клиент получает и отправляет данные на сервер с через формирование запросов по URL адресам.
JSON api - контракт о том что данные с сервера будут приходить в JSON формате. Данные могут приходить как ответы к REST запросам. А так же JSON api может быть реализован поверх других транспортов (websocket, webrtc).
REST не исключает, но и не ограничивается JSON api.
Примеры json api
http://jsonapi.org/examples/
Пример реализации JSON REST api
2 лайка
Т. е. особенность json api в том что ответы на запросы приходят от бекенда в строго оговоренном формате json?
А в RESTfull могут приходить в разных json’ах, я правильно вижу разницу? - Но это не вся разница, да?
различия можно явркво увидеть если сравнить пути решения одной и той же задачи разными способами - используя REST и JSON api
задача:
получить статью и детальную информация о авторе статьи
REST
GET /article/1 - получает статью
{
id: 1,
text: "some text",
created: 'date'
// etc
authorId: 3
}
делаем запрос за автором - GET /authors/3
{
id: 3,
name: "Petya",
dateOfBirth: '1989-09-12'
// etc
}
и задача решена.
JSON api
Здесь достаточно сделать всгео лишь один запрос GET /article/1?include=author
Получаем:
{
id: 1,
text: "some text",
created: 'date'
// etc
author: {
id: 3,
name: "Petya",
dateOfBirth: '1989-09-12'
// etc
}
}
В реальной жизний запросы будут намного сложнее и список include может быть длинным. JSON api позволяет сократить количество запросов на сервер в разы - посему он становится более популярным.
1 лайк
Верно.
В RESTfull может приходить XML в ответе, например.
Сравнивать JSON и REST не совсем корректно. Так как REST про транспорт и способ получения данных, а JSON про формат получения данных.
На прикладном уровне модели OSI есть такой протокол HTTP текстовый протокол передачи информации в WEB. У него есть ряд методов, для запроса, изменения, удаления информации.
Наиболее часто используемые - GET, POST, DELETE, UPDATE. Они позволяют реализовать CRUD - (create, read, update, delete) операции через HTTP протокол. На методах HTTP строится REST. По сути соглашение как использовать эти методы. Следовать ему не обязательно и каждый может пилить свой велосипед, но лучше ориентироваться на стандарты.
При обмене данными в методах HTTP, можно обмен вести в разных форматах - HTML, XML, JSON. Когда приходит HTML полной страницы это по сути то, что делают сайты - отдают HTML страницы на запрос ресурса. Но можно отдавать часть страницы, можно отдавать только данные без разметки в JSON, можно вообще текст вернуть или свой формат велосипедировать, опять же можно лепить свое, но лучше следовать стандартам.
Так вот один из стандартов обмена данными для обмена JSON это JSON API.
REST и JSON API разные вещи, REST - способ взаимодействия с сервером, JSON API один из вариантов представления данных которые будут ходить между сервером и клиентом, когда вы пользуетесь REST.
Читать что такое HTTP протокол, что такое REST, что такое JSON, что такое JSON API - в этой последовательности.
И не могу утерпеть, “backend”.
И да кроме HTTP есть уже другие протоколы, в частности упомянутый уже выше WebSoket.
2 лайка
Спасибо!
REST не является стандартом и не имеет спецификации, если есть пример хорошего туториала по RESTy или JSON API скинь ссылку.
Очевидно что имелся в виду общий подход ориентироваться на общепринятые подходы, а не изобретать свой велосипед. Кроме того, есть такое понятие “стандарт де-факто”.
Я как и многие, пришел к пониманию что такое REST “естественным” путем - через HTTP протокол (что и посоветовал) и программирование API. При программировании API я использовал ответ в виде JSON, тогда же возникла потребность как-то формализовать эти ответы и я наткнулся на JSON API. Но для моих задач JSON API это был оверхед и я его не использовал. Так же как многие не используют ничего подобного сложного. API бывают разные и часто концепции изложенные в подобных спецификациях избыточны.
Взять хотя бы ответы API Google они проще. По ним, кстати видно часто применяемый подход. В получаемом JSON есть data, может быть error, может быть какой-то message, принято указывать timestamp.
Что касается ссылок то по-моему первая ссылка с поиска гугл по словам “JSON API” ведет на http://jsonapi.org/, но опять-таки, насколько я понимаю, на данном этапе это не то что нужно.
То же самое с REST можно нагуглить, но дело не в REST, а в понимании HTTP если его понимать, то вопросы что такое REST вряд ли будут возникать.
И главное: Как и всегда, решение проблемы начинается с постановки задачи.
Какая задача стоит? Что нужно сделать? Из чего возникли вопросы породившие этот топик?
Тогда можно давать более точные советы.
P. S. Обычная проблема, что человек слабо разбирающийся в вопросе сложил свое представление о том что делать, но оно неверно или верно частично, т. к. он не видит всей картинки. Если идти на поводу этих неверных представлений, то толку мало. Это можно наблюдать во всех сферах, не только в программировании или ИТ. Поэтому ищущий должен формулировать задачу которую он решает, а не его представления что ему нужно для ее решения. А тот кого спрашивают, не должен позволить повести себя по неверному пути искаженных представлений о предмете, а должен выяснить первоначальную задачу и скорректировать путь решения.
2 лайка
Вопрос возник по необходимости построить REST взаимодействие клиента с сервером в собственном проекте, потренироваться и разобраться
Глобальный вопрос в том что бы стать разработчиком способным создавать приложения высокого уровня и знать все возможные способы архитектуры, взаимодействия и выбирать и пользоваться наиболее подходящими/
Я выбрал на этом этапе разобраться с JSON api / REST api
В принципе вопрос стал уже ясен и я могу реализовать взаимодействие на ресте
Отличный документ (на английском) как организовывать REST API в большой компании.
1 лайк