none
Web API 2: POST или PUT для подтверждения сущности RRS feed

  • Вопрос

  • Например, есть система, в ней есть сущности (запросы) от одного типа пользователей, есть другой тип пользователей, который может эти сущности или подтвердить, или отклонить. Какой тип предпочтительнее использовать в таком случае, PUT или POST ? По идее, POST должен создавать новый ресурс, но он его не создаёт (не будет вникать в детали реализации БД, т.к. это совсем другая абстракция), PUT по идее обновляет ресурс, но здесь ресурс как бы не обновляется как таковой, здесь совершаются некоторые действия около этого ресурса для конкретного пользователя.

    Как лучше реализовать?

    20 марта 2016 г. 15:07

Ответы

  • Я бы не сказал, что он так непопулярен, например Google в API своих сервисов использует PATCH.

    Но с другой стороны есть причины по которым его могут не использовать:

    - legacy code, PATCH относительно недавно был введен (RFC 5789, от марта 2010) и в старых проектах проще поддерживать текущее решение, чем переписывать;

    - по старой памяти, всегда делали PUT и все  работало, зачем менять;

    - PATCH не идемпотентный запрос и его реализация отличается от PUT/POST, так при отправке PATCH запроса должно быть передано описание изменений, а не просто новый или измененный объект, например:

    [
        { 
            "op": "replace",
            "path": "/email",
            "value": "new.email@example.org"
        }
    ]

    Вот тут это неплохо описано: http://williamdurand.fr/2014/02/14/please-do-not-patch-like-an-idiot/

    20 марта 2016 г. 21:15

Все ответы

  • Для этого можно использовать запрос PATCH, семантически он применяется для обновления части сущности.
    20 марта 2016 г. 18:22
  • Для этого можно использовать запрос PATCH, семантически он применяется для обновления части сущности.

    Я об этом думал, но запрос настолько малоиспользуемый, что я побаиваюсь его использовать...
    20 марта 2016 г. 18:34
  • В таком случае следует использовать PUT, он наиболее близок по смыслу к данному запросу. И как плюс он идемпотентный.

    20 марта 2016 г. 19:15
  • В таком случае следует использовать PUT, он наиболее близок по смыслу к данному запросу. И как плюс он идемпотентный.

    а почему тогда PATCH так непопулярен? Ведь подобных действий куда больше, чем чистых PUT/POST, вместе взятых
    20 марта 2016 г. 20:23
  • Я бы не сказал, что он так непопулярен, например Google в API своих сервисов использует PATCH.

    Но с другой стороны есть причины по которым его могут не использовать:

    - legacy code, PATCH относительно недавно был введен (RFC 5789, от марта 2010) и в старых проектах проще поддерживать текущее решение, чем переписывать;

    - по старой памяти, всегда делали PUT и все  работало, зачем менять;

    - PATCH не идемпотентный запрос и его реализация отличается от PUT/POST, так при отправке PATCH запроса должно быть передано описание изменений, а не просто новый или измененный объект, например:

    [
        { 
            "op": "replace",
            "path": "/email",
            "value": "new.email@example.org"
        }
    ]

    Вот тут это неплохо описано: http://williamdurand.fr/2014/02/14/please-do-not-patch-like-an-idiot/

    20 марта 2016 г. 21:15