Representations переводится как «представление». У клиента есть своё представление о ресурсе. Оно может меняться. Как мы помним из нашего примера, мы могли несколько раз изменять свой заказ. Для этого мы озвучивали свое представление того, как должен выглядеть наш заказ официанту, а тот, в свою очередь, повару.
Насколько я понимаю пример и REST, "мы" озвучивали "состояние" (S из REST) нашего заказа. А представление (R из REST) это немного другое. Использую то же пример, офицант и повар может иметь разные представления одного и тоже ресурса "https://ресторан/повар/заказы/заказ_для_столика_№4", например application/vnd.best.restaurant+waiter и application/vnd.best.restaurant+cook
Запросы офицанта
PUT https://ресторан/повар/заказы/заказ_для_столика_№4
content-type: application/vnd.best.restaurant+waiter
accept: application/vnd.best.restaurant+waiter
{
"первое блюдо": "суп с говядиной",
"горячее": "индейка в сливочном соусе",
"напиток": "лимонный компот"
}
GET https://ресторан/повар/заказы/заказ_для_столика_№4
accept: application/vnd.best.restaurant+waiter
{
"первое блюдо": "суп с говядиной",
"горячее": "индейка в сливочном соусе",
"напиток": "лимонный компот",
"статус": "в прогрессе"
}
Запросы повара (тот же ресурс - УРЛ, но другое представление - более понятное для повара)
GET https://ресторан/повар/заказы/заказ_для_столика_№4
accept: application/vnd.best.restaurant+cook
{
"первое блюдо": {
"название": "суп с говядиной",
"ингридиенты": ["10 грамм говядины", "500 грамм лука"]
},
"горячее": {
"название": "индейка в сливочном соусе",
"ингридиенты": ["индеейка или индеец", "соус по вкусу"]
},
"напиток": {
"название": "лимонный компот",
"ингридиенты": ["растворитель сока, со вкусом лимона", "вода"]
},
"статус": "в прогрессе"
}
Спасибо за стаью, интересно было прочитать. Но, под конец так и хотелось воскликнуть "It depends!".
Если сообщение в ошибке понятно любому, понятно описывает ситуацию и что пользователь дальше может сделать чтоб успешно завершить нужную операцию, то может же наоборот сгладить негативные чувтва пользователей при ошибках.
Вспоминаю многочисленные страницы сообщений сайтов. Это же целое исскуство :D
Ну согласитесь,
Упс, не возможно подключиться к вашему акканту
Ваши данные сохранились, но мы не можем.....
выглядит не так страшно?
Думаю, проблема не в юморе и неформальном тоне сообщения об ощибке, а в содержании.
Может дело и не в фин прибыле вовсе, в статье вроде также упоминалось что Сэм его нервировал некоторое время, про национальность и прочее. Может просто, банально отомстил когда выпал случай.
Из статьи я понял только одно, сначало Чанпэн снял одно колесо у махины (продав токены), потом решил помочь снял оставшиеся три. И конечно же, все это из искренне "добрых побуждений". R.I.P.
Тоже самое можно скзать про любой исторический факт и его разъеснение. Мое личное мнение, статья довольно интересная и полезная. Молодежи не обязательно проникаться, некоторые могут найти эту информацию просто занимательной. Тем более некоторые мемы используются до сих пор.
Да что уж там, я наверное уже не "молодежь", но многие факты из этой статьи не знал, не у всех Интернет случился в одно и тоже время, в одном и том же возрасте.
А просто прочитать 10 абзацев и просмотреть парочку картинок с информативной и исторической точки зрения, радоваться жизнью и продолжать клацать по кнопочкам, а не ныть, слабо? Тем более что в статье не нашел призыва пересесть на консоль.
Ну ты в Испании тоже "беженец". Почему это минус?
Четвертый год в Испании, не благожелательного начеления не встречал еще, чуть дольше пожить это сколько ждать?
Одно из них, например, что JWT зашифровано (на самом деле только подписано и закодировано base64)
Данное утвреждение либо неверно высказанно либо неверно понято. JWT RFC явно утвреждает обратное — JWT имеет возможность быть зашифровано (JWE). И эта возможность даже вынесена в отдельный RFC
Cryptographic algorithms and identifiers for use with this
specification are described in the separate JSON Web Algorithms (JWA)
[JWA] specification and an IANA registry defined by that
specification. Related encryption capabilities are described in the
separate JSON Web Encryption (JWE) [JWE] specification.
Что такое SDN, SD-WAN и тд я не знаю, не в теме, но рассказ прочитал с удовольствием. Спасибо, пятница прям стала лучше, а то за окном ливень с грядом :)
"Опытные разработчики" это от слово "опыт" или "пытка"? :) Если первое, вроде ничего странного что не сразу получается с "новшествами" или "новым синтаксисом", потому что как опыт получен в другом. И с этим появится и вопросов не будет.
Read-write-свойства не могу придумать нормальную альтернативу. Подскажете? Но без них не очень приятно делать DTO. Либо всё public, либо геттеры...
Мне лично нравится как в JS get property(), хотя там бывает проблема конфликтами если нужно такое же свойство. Вариант в PHP RFC решает эту пробелму, но так и вижу себя постоянно открывая доку ПХП чтоб вспомнить очередность get/set или set/get видимость :D
Должен быть один способ объявления свойств класса.
Это тебе повезло наверное в жизни, ты не читал код где свойства класса объявленны не в начале а между классами, что не запрещено. Я это к тому что в данном случае все дело в code standard, если в команде объявлен стандард что писать свойства в начале класса, то не сложно будет объявить что конструктор надо писать тоже сверху. Это кстати даже в RFC рекомендовано, и возможно появится в документации PHP. Остальное дело привычки. Думаю, не надо из-за своих привычек и желаний не давать другим возможности пользоваться чем-то.
<?php
class A {
public function __construct(public int $p = 1) {}
}
class B {
public int $p;
public function __construct(int $p = 1) {
$this->p = $p;
}
}
var_dump((new ReflectionClass(A::class))->newInstanceWithoutConstructor());
var_dump((new ReflectionClass(B::class))->newInstanceWithoutConstructor());
Коллега пытался сделать акцент на то, что «дешугаринг» должен нас спасти, но не спас.
Нет же. Я такого акцента не делал. Я делал акцент что это сахар и ничего не меняет в работе php. Вот так вы бы написали без сахара, и словили бы туже ошибку
class A {
public int $a;
public function __construct(int $a = 1) {
$this->a = $a;
}
}
class B extends A {
public string $b;
public function __construct(string $b = 'hello') {
$this->b = $b;
}
}
$b = new B();
var_dump($b->a, $b->b);
Насколько я понимаю пример и REST, "мы" озвучивали "состояние" (S из REST) нашего заказа. А представление (R из REST) это немного другое. Использую то же пример, офицант и повар может иметь разные представления одного и тоже ресурса "https://ресторан/повар/заказы/заказ_для_столика_№4", например
application/vnd.best.restaurant+waiter
иapplication/vnd.best.restaurant+cook
Запросы офицанта
Запросы повара (тот же ресурс - УРЛ, но другое представление - более понятное для повара)
Где-то я уже такое видел. Зато как красиво продали "runes" :)
Если уже "nothing", нового не надо же?!
Пример, настолько "выдуманный" что так и не показывает зачем это надо, а наборот доказывает что это код без монады будет проще и быстрее.
Спасибо за стаью, интересно было прочитать. Но, под конец так и хотелось воскликнуть "It depends!".
Если сообщение в ошибке понятно любому, понятно описывает ситуацию и что пользователь дальше может сделать чтоб успешно завершить нужную операцию, то может же наоборот сгладить негативные чувтва пользователей при ошибках.
Вспоминаю многочисленные страницы сообщений сайтов. Это же целое исскуство :D
Ну согласитесь,
выглядит не так страшно?
Думаю, проблема не в юморе и неформальном тоне сообщения об ощибке, а в содержании.
Может дело и не в фин прибыле вовсе, в статье вроде также упоминалось что Сэм его нервировал некоторое время, про национальность и прочее. Может просто, банально отомстил когда выпал случай.
Из статьи я понял только одно, сначало Чанпэн снял одно колесо у махины (продав токены), потом решил помочь снял оставшиеся три. И конечно же, все это из искренне "добрых побуждений". R.I.P.
Тоже самое можно скзать про любой исторический факт и его разъеснение. Мое личное мнение, статья довольно интересная и полезная. Молодежи не обязательно проникаться, некоторые могут найти эту информацию просто занимательной. Тем более некоторые мемы используются до сих пор.
Да что уж там, я наверное уже не "молодежь", но многие факты из этой статьи не знал, не у всех Интернет случился в одно и тоже время, в одном и том же возрасте.
А просто прочитать 10 абзацев и просмотреть парочку картинок с информативной и исторической точки зрения, радоваться жизнью и продолжать клацать по кнопочкам, а не ныть, слабо? Тем более что в статье не нашел призыва пересесть на консоль.
Ну ты в Испании тоже "беженец". Почему это минус?
Четвертый год в Испании, не благожелательного начеления не встречал еще, чуть дольше пожить это сколько ждать?
Данное утвреждение либо неверно высказанно либо неверно понято. JWT RFC явно утвреждает обратное — JWT имеет возможность быть зашифровано (JWE). И эта возможность даже вынесена в отдельный RFC
Что такое SDN, SD-WAN и тд я не знаю, не в теме, но рассказ прочитал с удовольствием. Спасибо, пятница прям стала лучше, а то за окном ливень с грядом :)
Буду признателен если поделишься своим мнение что такое "Репозиторий"
"Опытные разработчики" это от слово "опыт" или "пытка"? :) Если первое, вроде ничего странного что не сразу получается с "новшествами" или "новым синтаксисом", потому что как опыт получен в другом. И с этим появится и вопросов не будет.
Не совсем. В match могут быть инструкции и слева и справа, а не только значения
Мне лично нравится как в JS
get property()
, хотя там бывает проблема конфликтами если нужно такое же свойство. Вариант в PHP RFC решает эту пробелму, но так и вижу себя постоянно открывая доку ПХП чтоб вспомнить очередность get/set или set/get видимость :DЭто тебе повезло наверное в жизни, ты не читал код где свойства класса объявленны не в начале а между классами, что не запрещено. Я это к тому что в данном случае все дело в code standard, если в команде объявлен стандард что писать свойства в начале класса, то не сложно будет объявить что конструктор надо писать тоже сверху. Это кстати даже в RFC рекомендовано, и возможно появится в документации PHP. Остальное дело привычки. Думаю, не надо из-за своих привычек и желаний не давать другим возможности пользоваться чем-то.
А звучит как похороны.
Не магия, а короткий синтаксис. В примере A и B одинаковый код, один написаной с использованием сахара, другой без. Но код идентичный.
Так же как и без этого сахара.
Нет же. Я такого акцента не делал. Я делал акцент что это сахар и ничего не меняет в работе php. Вот так вы бы написали без сахара, и словили бы туже ошибку