Какие есть варианты обработки флагов и атрибутов в REST API?

Question

Допустим, у вас есть сложный ресурс в REST API. У вас есть несколько флагов и атрибутов «один ко многим» на этом ресурсе (т. Е. Пользователь мог присвоить ресурсу оценку от 1 до 5, или пользователь, возможно, «полюбил» ресурс или отметил его как спам, либо проигнорировал его, либо вызвал какое-то другое состояние, которое нужно установить).

Некоторые предложения были сделаны о том, как лучше представить это в архитектуре, ориентированной на ресурсы, но до сих пор никто из них не сделал меня по-настоящему счастливым. Итак, давайте толпо-источник этого; какие варианты вы находите проще всего понять? О каких вариантах мы не подумали? Предположим, что API основан на OAuth, и все здесь делается в контексте авторизованного пользователя.

• Булевы флаги

  • Вариант 1:

    GET /resource/{id}/muted
    POST /resource/{id}/muted BODY:true
    POST /resource/{id}/muted BODY:false
    

  • Вариант 2:

    GET /resource/{id}/muted
    PUT /resource/{id}/muted BODY:true
    DELETE /resource/{id}/muted
    

  • Вариант 3:

    GET /resource/{id}/attributes
    POST /resource/{id}/attributes BODY:muted=true
    POST /resource/{id}/attributes BODY:muted=false
    

  • Вариант 4:

    GET /resource/{id}/muted
    POST /resource/{id}/mute
    POST /resource/{id}/unmute
    

• Атрибуты

  • Вариант 1

    GET /resource/{id}/rating
    POST /resource/{id}/rating BODY:4
    

  • Вариант 2:

    GET /resource/{id}/rating
    PUT /resource/{id}/rating BODY:4
    DELETE /resource/{id}/rating
    

  • Вариант 3:

    GET /resource/{id}/attributes
    POST /resource/{id}/attributes BODY:rating=4
    POST /resource/{id}/attributes BODY:rating=
    

Мысли? Предложения? Как другие API справились с этим? Как вы справились с этим? Считаете ли вы, что подобные проблемы дизайна значительно повлияли на радость разработчиков или простоту использования ваших API?

Answer 1

С диссертация Роя :

унифицированный интерфейс снижает эффективность, поскольку информация передается в стандартизированной форме, а не в той, которая специфична для потребностей приложения. Интерфейс REST разработан для эффективной передачи крупномасштабных гипермедиа данных

Итак, вам нужен вариант 5, который работает как для флагов, так и для других атрибутов:

GET /resource/{id}/  BODY:{muted: false, like: false, rating: 2, ignored: true}
POST /resource/{id}/ BODY:{muted: true, like: false, rating: 2, ignored: true}
POST /resource/{id}/ BODY:{muted: false, like: false, rating: 2, ignored: true}

Одна из серьезных причин заключается в том, что большая часть эффективности HTTP-приложения RESTful достигается за счет кэширования, и это работает лучше всего, когда его артефакты достигают максимально возможного размера и когда его данные достижимы при минимально возможном количестве идентификаторов. Если вы выставите флаг 'muted' в /resource/{id}/ и /resource/{id}/muted, то у вас возникнет проблема аннулирования кэша. Если вы выставите его только на /resource/{id}/, тогда вы не сделаете.

Если вы разрабатываете приложение, которое нацелено на повышение эффективности за счет небольших полезных нагрузок, то вы не сможете извлечь выгоду из большого размера кэширования, а архитектурный стиль REST не подходит для вашего приложения. HTTP, вероятно, тоже нет, но я могу понять, как кто-то может застрять на сегодняшнем рынке.

Answer 2

Мне нравится Вариант 3, если я могу предоставить пакет сразу - иначе я равнодушен между 1 и 3.

И, безусловно, ничего, что использует DELETE.