здесь присутствует явное название метода (turnOn), который отражает вызов процедуры, а не работу с ресурсом, а /lamp/kitchen1 показан как входной параметр, т.е. как часть данных, передаваемых в процедуре, а не как самостоятельный ресурс
HTTP - это все же транспорт. RESTful API может использовать и другие протоколы передачи, просто HTTP больше всех поддерживает базовые принципы REST, поэтому его используют в связке с REST чаще всего.
Про HTTP-статусы: 1. При проектировании API не использую в качестве ответа код 404, его оставляю все-таки как транспортную ошибку. когда хочу проиллюстрировать пользовательскую ошибку в данных, беру HTTP-код 400, а в теле делаю 2 поля: error_code, error_description. Решение в лоб, но рабочее. Для прав доступа есть код 403.
2. Можно добавить специальные поля в HTTP-заголовки ответа, где явно показывать источник ошибки: endpoint или resource.
В идеале можно скомбинировать оба способа для удобства дальнейшей классификации, если видов ошибок достаточно много
Про HTTP-глаголы:
могу ответить кратко, а могу включить этот вопрос в одну из следующих статей, где рассмотрю это подробно. что выберете? :)
IPP соблюдает большинство принципов REST (клиент-серверный, без состояний, кешируемый, манипулирует ресурсами через представления GET, POST и тд), но не поддерживает HATEOAS. А в статье мы как раз говорили о том, что если придерживаться формальных определений, то без гипермедиа REST'ом называться нельзя. Но мы ориентируемся на практику, где 99% методов не используют гипермедиа и претендуют на звание REST-like. Поэтому и для IPP предлагаю использовать звание REST-like. :)
Спасибо! Kubernetes, API-гейтвеи упомянуты именно в конце, чтобы напомнить о том, что многие проблемы решаются готовыми инструментами, и нет смысла изобретать велосипед, если готовые инструменты вам доступны. А также не стоит забывать, что готовые решения стандартизированы и могут повлечь кастомные проблемы, для избежания которых можно использовать советы из статьи. :)
Думаю, нельзя.
здесь присутствует явное название метода (turnOn), который отражает вызов процедуры, а не работу с ресурсом, а
/lamp/kitchen1показан как входной параметр, т.е. как часть данных, передаваемых в процедуре, а не как самостоятельный ресурсПотому что это иллюстрация уровня 1, где глаголы еще не используются в полной мере
Один комментарий, а сколько интересного! :)
HTTP - это все же транспорт. RESTful API может использовать и другие протоколы передачи, просто HTTP больше всех поддерживает базовые принципы REST, поэтому его используют в связке с REST чаще всего.
Про HTTP-статусы:
1. При проектировании API не использую в качестве ответа код 404, его оставляю все-таки как транспортную ошибку. когда хочу проиллюстрировать пользовательскую ошибку в данных, беру HTTP-код 400, а в теле делаю 2 поля: error_code, error_description. Решение в лоб, но рабочее. Для прав доступа есть код 403.
2. Можно добавить специальные поля в HTTP-заголовки ответа, где явно показывать источник ошибки: endpoint или resource.
В идеале можно скомбинировать оба способа для удобства дальнейшей классификации, если видов ошибок достаточно много
Про HTTP-глаголы:
могу ответить кратко, а могу включить этот вопрос в одну из следующих статей, где рассмотрю это подробно. что выберете? :)
Спасибо за интересный вопрос.
IPP соблюдает большинство принципов REST (клиент-серверный, без состояний, кешируемый, манипулирует ресурсами через представления GET, POST и тд), но не поддерживает HATEOAS. А в статье мы как раз говорили о том, что если придерживаться формальных определений, то без гипермедиа REST'ом называться нельзя. Но мы ориентируемся на практику, где 99% методов не используют гипермедиа и претендуют на звание REST-like. Поэтому и для IPP предлагаю использовать звание REST-like. :)
Спасибо! Kubernetes, API-гейтвеи упомянуты именно в конце, чтобы напомнить о том, что многие проблемы решаются готовыми инструментами, и нет смысла изобретать велосипед, если готовые инструменты вам доступны. А также не стоит забывать, что готовые решения стандартизированы и могут повлечь кастомные проблемы, для избежания которых можно использовать советы из статьи. :)