Senior Python engineer
  • Синхронизируем понимание REST

    Так ведь я не против ссылок. Я за них обеими руками. Меня просто до глубины души поразило что в википедии в URL-е используется глагол, как в каком то RPC :)

  • Синхронизируем понимание REST

    Наверное да. Но я ведь начал разговор с того, что в примере с википедии uri (href) содержит не адрес ресурса, а смесь ресурса и какого то уникального действия над ним.

  • Синхронизируем понимание REST

    Ни одна из ссылок (которые в uri) не содержит ни одного действия — это всё ссылки на ресурсы. Что делать с этими ссылками на ресурсы (читать их через GET, или что то добавлять через POST) знает клиент, но он не знает сами ссылки. Он знает только rel по которому он может найти интересующий его ресурс для нужного ему действия.

  • Синхронизируем понимание REST

    В указанной вами ссылке как раз всё верно оформлено в плане того что uri указывает на ресурс:

    <link rel="/linkrels/appointment/addTest" uri="/slots/1234/appointment/tests«/>
    Как видите здесь uri указывает на ресурс-контейнер тестов, в который можно добавить новый тест. А добавить его туда можно стандартным (в случае HTTP) способом — через метод POST.

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

  • Синхронизируем понимание REST

    Про это уже писали на Хабре (в блоге Яндекса) в первом пункте.

  • Синхронизируем понимание REST

    Все действия, которые не вписываются в HTTP методы (CRUD) для конкретного ресурса можно реализовать теми же самыми методами для другого ресурса. Например может быть ресурс /copier, в который с помощью метода POST добавляется «задача» на копирование одного или нескольких ресурсов. Эта «задача» — такой же ресурс, и на сервере она может выполнятся асинхронно, а клиент, делая GET запрос к этой «задаче», будет получать её текущее состояние (например «выполнено: 56%»).
    Такой подход позволяет вписать в терминологию CRUD практически любую предметную область.

  • Синхронизируем понимание REST

    С таким форматом ссылок «на действия» это получается тот же самый RPC. Просто подмена одного стандарта на другой. Т.е. вместо того что бы клиент знал, что он может вызывать у ресурса GET, POST, PUT, DELETE, он будет знать, что ему нужно просто всегда вызывать POST на ту ссылку которую он найдёт в ответе на предыдущий запрос. Т.е. теряется какой либо смысл всех этих HTTP методов, если можно обойтись только GET и POST, а действие указывать в URL (например: /posts/123/comments/add_comment, /posts/123/comments/456/delete_comment)

    Поддержал: Gennady Dogaev
  • Синхронизируем понимание REST

    Я всё удивляюсь примеру про счёт в банке, который копируют с википедии. Я конечно не читал диссертацию Роя, и возможно в ней нет ничего про то что URI (в данном примере URL) должен указывать на ресурс, а не на действие. Объясните каким образом ссылка вида

    http ://somebank.org/account/12345/close
    может относится к REST поверх HTTP? Ведь эта ссылка указывает не на ресурс, а на действие с ним (close). В моём понимании такие ссылки должны указывать на связанные ресурсы (например /account/12345/transactions/ - список транзакций для данного счёта). В то время как перечень операций с ресурсом ограничен простыми HTTP методами (GET, POST, PUT, PATCH, DELETE), и этот список можно узнать сделав запрос OPTION для ресурса.
    Поддержали: Rezidentka, Gennady Dogaev