На сколько глубоко могут уходить подколлекции в нэйминге URI в REST?До 2к символов, в целом написание таких длинных запросов не противоречит идеологии rest, т.к. rest это не про то какой длины должен быть url, а про стиль взаимодействия.
:id/profiles/:id/tags/:id/color/:id/more-fields/:id/more-fields/:id/more-fields/:idКонкретно в этом случае используется странное решение(на мой взгляд), и не совсем понятно зачем так делать, т.к. задавать это все через параметры проще. Но т.к. rest это просто стиль архитектуры, то вам никто не запретит так делать, но если кому-то достанется такой код, то он будет не в восторге.
И теперь я хочу сделать апишку для получения информации о каждом тэге. Или хочу его изменить. С одной стороны мы можем использоватьв данном случае возможно имеет еще смысл таких url до 2-го id на id тегов уже явно бесполезно и его проще задать параметром, хотя можно сделать, чтобы только id аккаунта был в url, всё остальное можно засунуть в параметры, но тут я не знаю архитектуры приложения, возможно вам так удобнее или проще.
GET /accounts/:id/profiles/:id/tags/:id
wget -O- http://hldns.ru/update/%ключ который будет в письме hldns%
public class Result
{
public bool error {get;set;}
public string error_text {get;set;}
public List<Users> content {get;set;}
}List<Users> content = new();
return json(new {error = false, error_text = "", content = content});
откуда лучше брать сервера?
Получается должен быть какой-то Бекенд, на чём его писать?
Какие нагрузки он может выдерживать, тут ещё получается надо бы, чтобы эта система сама себя масштабировала, сигнализировала, если сервера перегружены, чтобы надо было ещё подключить.
Может быть есть уже какой-то готовый сервис который предлагает готовое решение
вычистит из этой скомпилированной библиотеки неиспользуемые функции
