Ответы пользователя по тегу RESTful API
  • Как спроектировать RESTful API?

    DmitriyEntelis
    @DmitriyEntelis
    Думаю за деньги

    Как-то все не оптимально и на RESTful не оч похоже, посоветуйте пожалуйста, как это вообще организовывают обычно?

    Советую: RESTful хорошо смотрится только в наглухо синтетических примерах абстрактного каталога объектов без бизнес-логики и взаимосвязей.

    но это какой-то странный restful,
    POST user/:userUuid/course

    А почему не POST /course/? У вас курс - самостоятельный объект, это не свойство юзера же.
    Ответ написан
    2 комментария
  • Возможно ли ограничить размер ответа от REST API?

    DmitriyEntelis
    @DmitriyEntelis
    Думаю за деньги
    1. слишком большой - понятие субъективное.
    я работал с api размер ответа которых исчислялся десятками и даже сотнями мегабайт.

    2. Разумеется ограничение размера делается не на уровне "отрезать кусок ответа", а на уровне бизнес-логики.
    Если это какой-то слишком большой список - делаем возможность запроса с limit/offset.
    Если есть какие-то тяжелые поля в объектах которые отдаются - делаем возможность исключения этих полей из ответа

    итд.
    Ответ написан
    Комментировать
  • Защита токена на стороне клиента?

    DmitriyEntelis
    @DmitriyEntelis
    Думаю за деньги
    Я больше беспокоюсь о том, что пользователь может прямо в консоли отправить запрос на перезапись данных.
    Все что ушло на клиент - Вам больше не принадлежит.
    Хотите как-то привязаться к бизнес-логике своего проекта, своим статусам итд - пишите на своем бекенде мини сервис, который будет пробрасывать запросы во внешний сервис, заодно делая все необходимые проверки на бизнес-логику итд.
    Ответ написан
  • Правильно ли я понимаю суть RESTFul?

    DmitriyEntelis
    @DmitriyEntelis
    Думаю за деньги
    Есть хорошая статья: habrahabr.ru/post/204958
    Если кратко: на чистом REST не получится сделать сложную бизнес логику.
    Ответ написан
    Комментировать
  • Rest API для своего сайта, с чего начать?

    DmitriyEntelis
    @DmitriyEntelis
    Думаю за деньги
    Начать с дизайна приложения.
    По дизайну становится понятно какие методы API нужны.
    Ответ написан
    Комментировать
  • Какие http коды ошибок возвращать?

    DmitriyEntelis
    @DmitriyEntelis
    Думаю за деньги
    Есть 2 точки зрения.
    Классический REST говорит что надо отдавать ошибки в http кодах сервера.
    На практике занимались разработкой api под мобильные приложения несколько лет и столкнулись с тем, что многие библиотеки используемые для работы с апи на мобильных приложениях:
    а) хреново работают с любым заголовком отличным от 200
    b) хреново работают с любыми методами отличными от GET/POST

    В итоге пришли к следующему решению (кусок из внутренней документации):
    84e91208aadc415ea342aa6f822275ea.png
    где code 400 говорит о том что серверу не нравятся какие то данные в запросе, error_code говорит о том что именно не нравится (почта, пароль итд - список свой в каждом методе api)
    Ответ написан
    Комментировать
  • Как правильно именовать сложные действия в REST API?

    DmitriyEntelis
    @DmitriyEntelis
    Думаю за деньги
    Все imho
    1) POST /missiles/[id]/launch мне кажется вполне нормальным
    2) POST /missile/[id]/country/[id] мне кажется вполне нормальным
    3) POST /country/[id]/destroy ;)
    4) POST /parade/start
    Ответ написан
    Комментировать
  • Как правильно авторизоваться через API?

    DmitriyEntelis
    @DmitriyEntelis
    Думаю за деньги
    Вполне нормальная.
    Ответ написан
    Комментировать
  • Как правильно разработать легкомасштабируемую платёжную систему?

    DmitriyEntelis
    @DmitriyEntelis
    Думаю за деньги
    1. Скрипт на крон - однозначно плохая идея. Более правильная история - постоянно работающий скрипт который из очереди получает очередную задачу. Отличный вариант для организации очереди rabbitmq

    2. Слабая связанность компонент это хорошо. В вашем случае однозначно api (не очень правда понимаю метания от php к java но дело Ваше. пишите на том, что лучше знаете) + расширяемые апи для внешних интеграций + интерфейсы цепляемые к апи.

    По поводу синхронности/асинхронности - это вполне можно уместить в одном апи. Какие методы делать синхронными, какие нет - целиком зависит от вашей бизнес логики.
    На мой взгляд получение баланса например вполне можно сделать синхронным.

    3. С точки зрения быстродействия - Вы достаточно быстро упретесь в базу. Соответственно надо сразу думать о шардировании данных, о том как система будет себя вести в случае выхода из строя одной из задействованных в транзакции нод итд.

    4. Вам важна data consistency. Сразу думайте про железо. Любые сервера горят. Брендовые сервера горят точно так же как и не брендовые. С учетом п3 - я бы делал полностью независимые друг от друга ноды, с физическим дублированием внутри ноды, и привязывал каждый счет к одной ноде.

    5 [философский] Поймите важный момент - без ОЧЕНЬ серьезных инвестиций в маркетинг, проекты не взлетают. Если бы эти инвестиции были - Вы бы тут не писали (не в обиду). Соответственно вероятность того что к Вам внезапно придет огромный поток транзакций - стремится к нулю. К тому моменту когда Вы раскрутитесь - Вы успеете 5 раз сменить архитектуру проекта. Нельзя иметь одну архитектуру у стартапа собранного одним человеком, и у проекта с высокими HL/HA.
    Пишите на чем нравится, у Вас будет куча времени что бы переписать узкие места например на C.

    6 [юридический] Вы в курсе что Вам нужна пачка лицензий на осуществление деятельности в качестве оператора электронных денег и денежных переводов без открытия банковского счёта? :)

    PS Я хочу верить что Ваш вопрос - это задачка для саморазвития. Иначе я не представляю себе что это за система платежная, которую делает один человек, спрашивающий совета как делать такие штуки (опять же не в обиду Вам ) :)
    Ответ написан
    Комментировать
  • REST API Яндекс.Диска - как сделать logout?

    DmitriyEntelis
    @DmitriyEntelis
    Думаю за деньги
    Если вы хотите разлогиниться - сотрите у себя полученный token :-)
    Ответ написан
    2 комментария