Попытаюсь ответить на все вопросы/замечания:
Q. Откуда вообще взялся HTTP? Мы же выяснили, что HTTP не обязателен для REST… или нет?
A. Если речь идет про REST, то да, HTTP не обязателен. Но если речь идет про модел RMM, то тут HTTP уже обязателен.
RMM — это модель, который строен на основе RESTЯ. Я могу сам создать какой-то модель,
который будет удовлетворять всем пунктам REST и назвать его моделю Шурика. Если веб сервис будет удовлетворять этой модели, то он тоже будет RESTfull.
Единственное отличное будет, что про модель Шурика буду знать только я, а RMM является общепринятым.
Q. Эмм. SOAP, знаете ли, не REST. Так зачем оценивать SOAP-сервис по REST-классификации?
A. Поскольку SOAP — это реализация веб сервиса, а REST — это архитектурный стил.
Вы же можете взять любой класс и сказать является ли он синглтон или нет? Почти тоже самое тут.
Q. … и как определить, какое использование «правильное»?
A. Тут нет спецификации, нет конкретного определения, что так правильно, а так нет.
Нужно просто, чтобы бизнес логика соответствовала описанию статус кодов, вот например:
201 Created
The request has been fulfilled, resulting in the creation of a new resource.
Если этот код будет возвращен при удалении записи, будет неправильно.
Q. Вы не знаете, насколько это требование актуально для веб-служб, но все равно утверждаете (позже), что именно этот уровень говорит о том, что сервис — RESTful. Хм…
A. По модели RMM, если ваш сервис не поддерживает HATEOAS, то его можно считать только частично RESTful.
На счет актуальности — это мое субьективное мнение. Инымы словами, я не знаю насколько актуально иметь полноценню RESTfull службу.
А HATEOAS — это обязательное ограничение для REST.
Q. А вот теперь — хороший вопрос: какой же уровень RMM у амазоновских сервисов?
A. Надо проверить. Что-то мне кажется, что HATEOAS они не поддерживают.
Q. Нет. Диссертация Филдинга описывает архитектурный стиль, а не архитектуру.
A. Согласен. Правильнее будет «Архитектурный стиль».
Q. Откуда вообще взялся HTTP? Мы же выяснили, что HTTP не обязателен для REST… или нет?
A. Если речь идет про REST, то да, HTTP не обязателен. Но если речь идет про модел RMM, то тут HTTP уже обязателен.
RMM — это модель, который строен на основе RESTЯ. Я могу сам создать какой-то модель,
который будет удовлетворять всем пунктам REST и назвать его моделю Шурика. Если веб сервис будет удовлетворять этой модели, то он тоже будет RESTfull.
Единственное отличное будет, что про модель Шурика буду знать только я, а RMM является общепринятым.
Q. Эмм. SOAP, знаете ли, не REST. Так зачем оценивать SOAP-сервис по REST-классификации?
A. Поскольку SOAP — это реализация веб сервиса, а REST — это архитектурный стил.
Вы же можете взять любой класс и сказать является ли он синглтон или нет? Почти тоже самое тут.
Q. … и как определить, какое использование «правильное»?
A. Тут нет спецификации, нет конкретного определения, что так правильно, а так нет.
Нужно просто, чтобы бизнес логика соответствовала описанию статус кодов, вот например:
201 Created
The request has been fulfilled, resulting in the creation of a new resource.
Если этот код будет возвращен при удалении записи, будет неправильно.
Q. Вы не знаете, насколько это требование актуально для веб-служб, но все равно утверждаете (позже), что именно этот уровень говорит о том, что сервис — RESTful. Хм…
A. По модели RMM, если ваш сервис не поддерживает HATEOAS, то его можно считать только частично RESTful.
На счет актуальности — это мое субьективное мнение. Инымы словами, я не знаю насколько актуально иметь полноценню RESTfull службу.
А HATEOAS — это обязательное ограничение для REST.
Q. А вот теперь — хороший вопрос: какой же уровень RMM у амазоновских сервисов?
A. Надо проверить. Что-то мне кажется, что HATEOAS они не поддерживают.
Q. Нет. Диссертация Филдинга описывает архитектурный стиль, а не архитектуру.
A. Согласен. Правильнее будет «Архитектурный стиль».