Иван Шумов
Solution Architect, AWS Certified, Serverless
-
вклад
-
2вопроса
-
1434ответа
-
28%решений
-
Как правильно задавать дату с временем в rest api для фильтрации данных (метод get)?
Нет правильного и неправильного - есть контракт. Хорошие и опытные люди используют timestamp (можно в milliseconds) по тому что он не зависит от часового пояса, но в некоторых случаях это можно смело игнорировать
PS если прямо отвечать на вопрос про
как поступать с пробелами и двоеточием
то как и со всем остальным - urlencode. Есть в каждом языке подобная трансформация3 комментария -
Какой должен быть правильный ответ для PUT и POST запросов в RESTful API?
любой 2xx является успешным, поэтому 204 отдается только когда тело ответа не будет отправлено. 201 Когда POST/PUT запрос успешно отработал и в ответе есть контент (не важно какой) -
Как правильно использовать вложенные сущности в ответе REST?
Не использовать. Для этого или думать уже про HAL/HATEOAS или в сторону GraphQL. REST под это дело работает, но очень плохо ложится в концепцию -
Долгий http запрос из мобильного приложения?
Latency сети в первую очередь. Поместите их в одну сеть и тогда результаты, вероятнее всего, будут близки -
Где взять готовые REST и SOAP сервисы?
Их не ставят, а программируют. Под любой язык легко гуглится как "LANGUAGE_NAME REST API tutorial" -
Обязательно ли должна быть meta при возврате ответа в Rest?
в концепции REST данной информации быть не должно. Ну, разве что в заголовках да и то не факт. REST оперирует только состоянием объектов системы -
Чем GraphQL лучше REST API?
Он не лучше и не хуже, просто у него другие цели. Pardon Me! Where Do I Find 4giveness? не полностью прав, GraphQL создавался как инструмент решения проблемы большого числа микросервисов и усложнения логики работы с ними (а то что чаще всего они работают по REST - просто совпадение).
Из бонусов у GraphQL есть subscription модель (для простоты - урезанный вебсокет).
Быстрее или нет он работает - совсем не корректный вопрос. Зависит от задачи и ее реализации -
Как правильно реализовать restapi с vuejs?
1) этот вопрос решается такой штукой как GraphQL. Очень рекомендую ознакомиться
2) увы, не фронт, не в теме -
Какой правильный принцип построения url?
Все варианты верные. По большей части разница в том что некоторые адреса проще роутить на разные микросервисы. Ну и личное предпочтение играет большую роль.
UPD. А использовать get параметры в таком виде считается моветоном, но в основном по тому что так труднее использовать однотипные адреса и "вложенные" ресурсы -
Как правильнее построить REST маршрутизацию?
Стоит задуматься скорее о том как будет использоваться API. Вот представьте - чтобы получить коммент надо знать id пользователя и поста. Нужна ли системе данная сложность? Мне кажется нет.
В REST в принципе делают связанные сущности таким образом только когда они не существуют . как . глобальный список (например у пользователя есть статус и его надо менять отдельно GET users/:id/status, PUT users/:id/status)
А правильного варианта нет, есть подходящий -
Как в REST сделать метод со сложной фильтрацией?
1. в rest для url не типично использовать символы в верхнем регистре. Стоит заменить TodoItems на todo-items
2. для фильтрации типично использовать GET параметры. Обычно для этого передают всякие разные параметры вроде filter, limit, page и т.п. и они отлично работают
3. если уж так очень хочется сложную фильтрацию запросами в теле то для этого сейчас используют GraphQL
4. Если вообще приспичило так то в GET тоже можно слать Body, просто мало кто про это знает, а в RFC написано что "поступайте так только если действительно понимаете что делаете"
5. самый верхний метод у вас и должен быть по совместительству фильтром -
Как грамотно организовать поддержку языков для приложения Clients - Server (RESTFULL)?
Способов куча - от добавления заголовков с предпочитаемым языком до query параметров. Зависит от того с чем и как надо работать. Understand your data, как говорится -
Для чего нужен REST?
Это просто стандарт, один из многих. Нужен он в первую очередь для того чтобы люди понимали друг-друга максимально точно, как и со всеми остальными контрактами.
В концепции REST:
POST - только для создания ресурсов
PUT - для перезаписи ресурсов
DELETE - для удаления ресурсов
а OPTIONS это просто спецификация HTTP и он для preflight запросов чтобы узнат ьможно ли клиенту выполнять операцию
REST никак не влияет на производительность -
Стоит ли один и тот же endpont в RESTlike API делать доступным и для авторизованного и не авторизованного пользователя?
Вам надо переосмыслить ваше API. Оба варианта пока что кажутся дикостью. Если детализируете что у вас за api, что делает этот конкретный метод то тогда можно помочь принять решение.
Вообще:
- выделите сущности системы (Entities of Domain Model хотябы)
- составьте список ролей и действий, которые они делать (UseCase)
- вот тут начнет проясняться -
Скорость преобразования данных от API?
Разница в обработке скорее всего зависит от загруженности процессора, поэтому не думаю что это криминал. Бэк не обязан отдавать формат в удобном вам виде. Преобразование форматов вообще абсолютно нормально по тому как это основа существования api, за исключением моментов когда используется подход BFF, да и то не всегда -
Взаимодействие микросервисов?
Все справочники можно выделить в отдельный микросервис, например. А ещё при большом объеме связанных ресурсов стоит уже смотреть на graphQL
- 1
- 2
- Следующие →