Да сказали же, что пример не очень удачный. Меня больше удивляет вся эта чехарда с PUT/POST запросами, когда каждый адепт по-своему придумывает правила.
Берем банальнейший пример, который идеально показывает провал идеологии rest, когда разные люди пытаются проектировать REST API.
Ban user command.
Как я себе представляю наиболее православный и одобренный богами REST способ:
PUT /users/{id}/banstatus - и тут уже передаем true или false. Но мне даже такой не нравится. Тут в зависимости от аргумента будут сгенерены разные эвенты(UserWasBlocked and UserWasUnblocked) это сродни функции с булевым аргументом(ban(bool $banned)), которую надо отрефакторить, разделив на две, для более удобного интерфейса. А разделив этот REST-ресурс на два, уже получим стандартный rpc.
Я немного погуглил. И на первой странице гугла по rest api ban user запросу такой разброс и шатание.
https://my.axerosolutions.com/spaces/5/communifire-documentation/wiki/view/5619/rest-api-ban-user - первое что у меня вылезло. Чистейший rpc под видом rest.
https://community.jivesoftware.com/thread/279984
Я еще недавно натыкался на PUT /users/{id}/status - значение нового статуса. А статусов было несколько(normal/banned/blocked/moderated - чот такое)! И там была специальная таблица что произойдет, когда нынешний статус такой то а новый такой то
) это было очень весело
А что меня больше всего порадовало, так это wrapper для REST API одного.
https://github.com/gnello/php-openfire-restapi#users
Тут сразу видно, что люди не хотят рест. Они хотят просто команд человечно-названных.
И я не понимаю зачем люди пытаются впихнуть человечный naming в нечеловечный гораздо более бедный HTTP-naming.
Берем банальнейший пример, который идеально показывает провал идеологии rest, когда разные люди пытаются проектировать REST API.
Ban user command.
Как я себе представляю наиболее православный и одобренный богами REST способ:
PUT /users/{id}/banstatus - и тут уже передаем true или false. Но мне даже такой не нравится. Тут в зависимости от аргумента будут сгенерены разные эвенты(UserWasBlocked and UserWasUnblocked) это сродни функции с булевым аргументом(ban(bool $banned)), которую надо отрефакторить, разделив на две, для более удобного интерфейса. А разделив этот REST-ресурс на два, уже получим стандартный rpc.
Я немного погуглил. И на первой странице гугла по rest api ban user запросу такой разброс и шатание.
https://my.axerosolutions.com/spaces/5/communifire-documentation/wiki/view/5619/rest-api-ban-user - первое что у меня вылезло. Чистейший rpc под видом rest.
https://community.jivesoftware.com/thread/279984
- Identify the user you want to do this to, and end up with a GET /api/core/v3/people/xxx to retrieve that person. Be sure you use fields=@all on whatever this final query is, so that a complete replace does what you expect.
- Set the jive.enabled field to false, and do a PUT /api/core/v3/people/xxx to deactivate the person.
Я еще недавно натыкался на PUT /users/{id}/status - значение нового статуса. А статусов было несколько(normal/banned/blocked/moderated - чот такое)! И там была специальная таблица что произойдет, когда нынешний статус такой то а новый такой то
) это было очень веселоА что меня больше всего порадовало, так это wrapper для REST API одного.
https://github.com/gnello/php-openfire-restapi#users
Тут сразу видно, что люди не хотят рест. Они хотят просто команд человечно-названных.
PHP:
//Delete a user
$result = $api->Users()->deleteUser('Username');
//Ban a user
$result = $api->Users()->lockoutUser('Username');
//Unban a user
$result = $api->Users()->unlockUser('Username');
