Здесь вообще один из авторов сравнивает UI-архитектуры с архитектурами распределенных систем и говорит, что MVC — это аналог всяких архитектур типа SOAP, CORBA или RMI (которые не взлетели), в то время как React следует RESTful стилю.
Красивая версионность — это в HTML. Будущее версионности API видимо тоже за подобным подходом — когда модель будет дополнительно описываться некоторыми тэгами или другими метаданными. При этом незнакомые тэги будут игнорироваться клиентом, а в случае несовместимых изменений будут вводиться новые тэги. Тогда старые клиенты смогут продолжать работу хотя бы частично.
А в чем проблема? Объясните свои затруднения. Авторизация не есть «состояние клиента» — это обязательная часть взаимодействия.
Поэтому OAuth, HTTP Basic, HTTP Digest — всё это правильные способы аутентификации для REST. Даже подписанная Cookie, содержащая ID пользователя подойдет.
С Cookie другая проблема — она часто используется именно для передачи ID сессии, хранящей клиентское состояние. Но если вы не используете сессию, то Cookie можно использовать как «workaround» против невозможности скормить браузеру собственный заголовок Authorization.
Если у вашего API это задокументировано, то всё нормально. Из той же области, что и использование параметра _method с POST запросом, когда PUT и DELETE не поддерживаются браузером.
Stateless-принцип просто означает, что сервер не должен хранить и использовать состояние клиента.
«Each request from client to server must contain all of the information necessary to understand the request, and cannot take advantage of any stored context on the server.» — первоисточник
Поэтому если пользователь однозначно идентифицируется через один из заголовков запроса (Autorization, например), то вполне можно использовать /me. Это часть взаимодействия, а не состояние клиента.
В ответ, можно например, сделать редирект на /users/gnomeby/products либо даже напрямую выдавать ответ. В последнем случае нужно не забывать дописать используемый заголовок-идентификатор в Vary ответа.
Мы часто путаемся из-за того, что есть состояние клиента и состояние сервера.
Собственно, «idempotence» в мире REST чаще всего используется по отношению к состоянию сервера и означает, что при нескольких применениях одного и того же метода сервер остается в одном и том же состоянии. Хотя по факту на клиенте вы можете получить разные ответы.
А тот же stateless-принцип просто означает, что нельзя держать состояние клиента на сервере (а точнее — менять поведение сервера в зависимости от состояния клиента).
Ну послушайте, опять статья про REST в которой нет ни одного упоминания гипертекста или HATEOAS (Кусок про «Link things together» засчитать за оные невозможно).
Это как бы и есть ключевое отличие REST (та самая суть, которую автор не уловил). Ссылки и их отношения вместо захардкоденых URI, медиа-типы и их описания вместо «описания форматов по заданным URI» — это про REST.
Модель работы браузер — сервер и есть модель RESTful приложения. Клиент (браузер) знает только протокол взаимодействия (http), умеет интерпретировать медиа-тип (html).
В умение интерпретировать медиа-тип включается и то, как интерпретировать встречающиеся в нем URI, как понимать их взаимоотношения. Например, один и тот же URL в тэгах «img», «a», «link» и «form method=post» интерпретируется по-разному, обеспечивая разные изменения состояния приложения.
Но в этом и есть основная проблема при реализации REST API в данный момент. Общепризнанных гипермедиа-типов очень мало (text/html, application/atom+xml) и использовать их можно далеко не для каждой задачи. А описывать собственный… это уже совсем не просто.
Есть три вида передачи аргументов: по значению, по ссылке и по копии ссылки.
Объекты передаются в функцию именно по копии ссылки. Таким образом даже если внутри функции значение меняется — оно меняется только у этой копии. Внешние переменные не затрагиваются.
Языков там много, но разработаны сообществами, а не самим фейсбуком. Да и инструменты уже появляются довольно регулярно, см. https://github.com/chentsulin/awesome-graphql
Здесь вообще один из авторов сравнивает UI-архитектуры с архитектурами распределенных систем и говорит, что MVC — это аналог всяких архитектур типа SOAP, CORBA или RMI (которые не взлетели), в то время как React следует RESTful стилю.
Поэтому OAuth, HTTP Basic, HTTP Digest — всё это правильные способы аутентификации для REST. Даже подписанная Cookie, содержащая ID пользователя подойдет.
С Cookie другая проблема — она часто используется именно для передачи ID сессии, хранящей клиентское состояние. Но если вы не используете сессию, то Cookie можно использовать как «workaround» против невозможности скормить браузеру собственный заголовок Authorization.
Если у вашего API это задокументировано, то всё нормально. Из той же области, что и использование параметра _method с POST запросом, когда PUT и DELETE не поддерживаются браузером.
«Each request from client to server must contain all of the information necessary to understand the request, and cannot take advantage of any stored context on the server.» — первоисточник
Поэтому если пользователь однозначно идентифицируется через один из заголовков запроса (Autorization, например), то вполне можно использовать /me. Это часть взаимодействия, а не состояние клиента.
В ответ, можно например, сделать редирект на /users/gnomeby/products либо даже напрямую выдавать ответ. В последнем случае нужно не забывать дописать используемый заголовок-идентификатор в Vary ответа.
Собственно, «idempotence» в мире REST чаще всего используется по отношению к состоянию сервера и означает, что при нескольких применениях одного и того же метода сервер остается в одном и том же состоянии. Хотя по факту на клиенте вы можете получить разные ответы.
А тот же stateless-принцип просто означает, что нельзя держать состояние клиента на сервере (а точнее — менять поведение сервера в зависимости от состояния клиента).
$a = «stuff». PHP_EOL;
А вам придется все запятые заменять.
Как раз для таких случаев Рой Филдинг и отрезал раз и навсегда: Если изменение состояния приложения не продиктовано гипертекстом — оно не может считаться RESTful.
Это как бы и есть ключевое отличие REST (та самая суть, которую автор не уловил). Ссылки и их отношения вместо захардкоденых URI, медиа-типы и их описания вместо «описания форматов по заданным URI» — это про REST.
Модель работы браузер — сервер и есть модель RESTful приложения. Клиент (браузер) знает только протокол взаимодействия (http), умеет интерпретировать медиа-тип (html).
В умение интерпретировать медиа-тип включается и то, как интерпретировать встречающиеся в нем URI, как понимать их взаимоотношения. Например, один и тот же URL в тэгах «img», «a», «link» и «form method=post» интерпретируется по-разному, обеспечивая разные изменения состояния приложения.
Но в этом и есть основная проблема при реализации REST API в данный момент. Общепризнанных гипермедиа-типов очень мало (text/html, application/atom+xml) и использовать их можно далеко не для каждой задачи. А описывать собственный… это уже совсем не просто.
В случае с аватаром — перезалить не проблема, но ведь будет множество других случаев, где плагин не сможет того, что предлагает WebIntents.
Штука крутая, несомненно.
Объекты передаются в функцию именно по копии ссылки. Таким образом даже если внутри функции значение меняется — оно меняется только у этой копии. Внешние переменные не затрагиваются.
Угодить всем не получится.