Закон Demeter по сравнению с REST
Нет необходимости создавать обещание с помощью new Promise, когда у вас есть таблица.
Вы можете просто вернуть return result.then(...... или, если хотите быть уверенным, вернуть экземпляр Promise (а не только то, что возвращает then().catch()), а затем передать результат: Promise.resolve()
if (typeof result.then === "function") {
return Promise.resolve(result).then(function (result) {
if (result !== undefined) {
return { status: 0, result: result };
}
return { status: 0 };
})
.catch(function (err) {
if (typeof err === "object") {
return { status: 400, errorMessage: err.name + ", " + err.message, stack: err.stack };
}
return { status: 400, errorMessage: err };
});
}
catch возникает ошибка, возвращаемое обещание разрешается как отклоненное. Вызывающий может справиться с этим с помощью своего собственного catch прикованного к нему.
4 ответа
- Является ли Demeter нереальным в любом сценарии сервер / клиент?
Я думаю, что вы ответили здесь на свой вопрос. Чем REST таким образом отличается от SOAP или XML-RPC в этом отношении?
Суть REST не является чтобы обеспечить сверхслабую связь, но следующее:
- Предоставить идентификатор, который точно описывает запрашиваемый ресурс.
- Предоставить сервисы, которые ведут себя как ожидается
GETзапросы являются идемпотентными,PUTобновляет записи,создает POST,УДАЛЯЕТудаляет - Минимизирует состояние, сохраняемое на сервере
- Сносит ненужную сложность
В некоторых случаях REST не лучший ответ,
Я не обращаю внимания на этот закон / предложение. Он побеждает половину выгоды от агрегации и композиции, и у меня ее не будет.
Ссылка, предоставляемая представлением, предоставляемым интерфейсом RESTful, может быть полностью непрозрачной, не нарушая ни одного из REST ограничения. Поэтому я бы предположил, что REST полностью соответствует закону Деметры. Не требуется, чтобы ссылка отображала структуру пространства URL в своем URL.
Например, в объектно-ориентированном сценарии вы можете заменить вызов abc на a.bc
В представлении RESTful вы можете создать следующее :
<a>
<link href="bc"/>
</a>
вместо того, чтобы делать
GET a
<a>
<link href="b"/>
</a>
GET b
<b>
<link href="c"/>
</b>
GET c
, я бы не согласился с altCognito и сказал, что одной из основных целей REST является слабая связь. Единый интерфейс, стандартные типы носителей и HATEOAS - все это в совокупности создает чрезвычайно слабосвязанный интерфейс.
В ответ на комментарий Дэвида:
REST - это очень слабая связь до точки, когда провайдеру бессмысленно пытаться предугадать все потребности клиентов.
На самом деле, REST ограничивает возможности клиентов, предоставляя только действительные ссылки в представления. В рамках этих ограничений клиент может попытаться удовлетворить свои собственные потребности. Именно удаляя знания от клиента о том, когда могут быть сделаны определенные запросы, вы достигаете слабой связи. Слабая связь не достигается путем перечисления набора ресурсов и произнесения «хорошо, вы можете ПОЛУЧИТЬ, ПОСТАВИТЬ, ПОСТИТЬ, УДАЛИТЬ все, что вы хотите».
В рамках этих ограничений клиент может попытаться удовлетворить свои собственные потребности. Именно удаляя знания от клиента о том, когда могут быть сделаны определенные запросы, вы достигаете слабой связи. Слабая связь не достигается путем перечисления набора ресурсов и произнесения «хорошо, вы можете ПОЛУЧИТЬ, ПОСТАВИТЬ, ПОСТИТЬ, УДАЛИТЬ все, что вы хотите». В рамках этих ограничений клиент может попытаться удовлетворить свои собственные потребности. Именно удаляя знания от клиента о том, когда могут быть сделаны определенные запросы, вы достигаете слабой связи. Слабая связь не достигается путем перечисления набора ресурсов и произнесения «хорошо, вы можете ПОЛУЧИТЬ, ПОСТАВИТЬ, ПОСТИТЬ, УДАЛИТЬ все, что вы хотите».Я думаю, что они действительно ортогональны. REST описывает набор ресурсов, адресованных URI, с помощью набора канонических методов: GET, POST и т. Д. Если процедура REST возвращает URI, это не значит, что она «достигает цели», она идентифицирует другой объект с теми же именами методов.