Привет! Спасибо за комментарий. Для случая /api/book/350/page/12 одной ошибки 404 точно будет мало, тк влечет неопределенность, которую мы дополняем типизацией ошибки в теле ответа. а Для случая /api/orders/999 отвечт не будет двойственным, поэтому тело можно не прикреплять.
Ошибка 403 дословно читается как "я понял, кто вы, но вам туда нельзя". Тип запрета зависит от вашего сервиса: если у вас книжный магазин, то покупателю нельзя производить никакие изменения в книгах, поэтому дополнительных пояснений к ошибке 403 не понадобится. А если у вас портал, где есть читатели и авторы, которые могут редактировать свое, а чужое не могут, тогда вас спасет описание ошибки в теле.
Про "клиенту приходится проверять и статус, и поле в теле". Здесь скорее о простых случаях, когда статус МОЖЕТ сказать сам за себя и доп.поле не требуется. В моей практике такие случаи нечасты.
При использовании HTTP и WebSocket понятие единого интерфейса не применимо
здесь присутствует явное название метода (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-гейтвеи упомянуты именно в конце, чтобы напомнить о том, что многие проблемы решаются готовыми инструментами, и нет смысла изобретать велосипед, если готовые инструменты вам доступны. А также не стоит забывать, что готовые решения стандартизированы и могут повлечь кастомные проблемы, для избежания которых можно использовать советы из статьи. :)
Привет!
Спасибо за комментарий.
Для случая /api/book/350/page/12 одной ошибки 404 точно будет мало, тк влечет неопределенность, которую мы дополняем типизацией ошибки в теле ответа. а Для случая /api/orders/999 отвечт не будет двойственным, поэтому тело можно не прикреплять.
Ошибка 403 дословно читается как "я понял, кто вы, но вам туда нельзя". Тип запрета зависит от вашего сервиса: если у вас книжный магазин, то покупателю нельзя производить никакие изменения в книгах, поэтому дополнительных пояснений к ошибке 403 не понадобится. А если у вас портал, где есть читатели и авторы, которые могут редактировать свое, а чужое не могут, тогда вас спасет описание ошибки в теле.
Про "клиенту приходится проверять и статус, и поле в теле". Здесь скорее о простых случаях, когда статус МОЖЕТ сказать сам за себя и доп.поле не требуется. В моей практике такие случаи нечасты.
При использовании HTTP и WebSocket понятие единого интерфейса не применимо
Думаю, нельзя.
здесь присутствует явное название метода (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-гейтвеи упомянуты именно в конце, чтобы напомнить о том, что многие проблемы решаются готовыми инструментами, и нет смысла изобретать велосипед, если готовые инструменты вам доступны. А также не стоит забывать, что готовые решения стандартизированы и могут повлечь кастомные проблемы, для избежания которых можно использовать советы из статьи. :)