Rest services. Best Practices.

[newyorker]

Начальник требует что бы в POST запросах не было никаких id.
Т.е. если нужно например сохранить список preferences для определенного юзера, то и список preferences и user id требует передавать через сессию.
А мне кажется что нужно что бы url был
user/{id}/preferences

Прав я или не прав, и как его убедить? Или не принципиально?
Вообще, есть ли какие то стандарты качественных rest url?

[kostik78]

ну restful говорит что нужно через url. А как начальника аргументирует? Гиг на секьюрити?

[newyorker]

ну restful говорит что нужно через url.

Не нашел чтоб конкретно советовали id через url посылать.


Начальник например вот прислал
http://stackoverflow.com/questions/6119 ... dea-or-not
You want reasons? Here's one:

A web form can't be used to send a request to a page that uses a mix of GET and POST. If you set the form's method to GET, all the parameters are in the query string. If you set the form's method to POST, all the parameters are in the request body.

Source: HTML 4.01 standard, section 17.13 Form Submission

[helg]

А простой user1 по задумке должен иметь возможность сохранять список preferences для user2, или только для себя?

[newyorker]

А простой user1 по задумке должен иметь возможность сохранять список preferences для user2, или только для себя?

для любого юзера конечно. Иначе пример бы не имел смысла

[kostik78]

Имхо бред. Берем например известный продукт - elasticsearch. Там POST/PUT имеет и параметры и тело и оба можно миксовать. В моей конторе также в нашем api. Или twilio (если не ошибаюсь).

Я знаю только один good reason когда что-то не рекомедуется передавать в POST как парамеры - это что-то сенсетив типа паролей, сессии и любую информацию что попадает под PII. Причина проста, url request может быть кеширован и эта инфа попадет в кеш. Body никогда(почти) не кешируется.

[newyorker]

Имхо тоже бред. Но мне бы побольше аргументов Или авторитетных источников со стандартами.

[kostik78]

я боюсь что стандарта на эти вещи нет. Я не встречал. Есть common practice которая не запрещает делать микс параметров и боди для POST/PUT кроме случая что я описал (PII)

[helg]

А простой user1 по задумке должен иметь возможность сохранять список preferences для user2, или только для себя?

для любого юзера конечно. Иначе пример бы не имел смысла

Очень странно. На форуме, например, простой пользователь может менять только свои собственные настройки.

[newyorker]

А простой user1 по задумке должен иметь возможность сохранять список preferences для user2, или только для себя?

для любого юзера конечно. Иначе пример бы не имел смысла

Очень странно. На форуме, например, простой пользователь может менять только свои собственные настройки.

А админ может менять настройки любого. Или банить любого. Или в группу добавлять любого. Вы не к примеру придирайтесь, а лучше по сути скажите

[helg]

А админ может менять настройки любого. Или банить любого. Или в группу добавлять любого. Вы не к примеру придирайтесь, а лучше по сути скажите

Именно что админ.
Авторизацию: что данному пользователю позволено, а что - нет, принято писать не в коде бизнес-логики, а слоем поверх неё. Чтобы авторизация была как вахтёр на проходной: есть пропуск фиолетового цвета - проходи в фиолетовый корпус, нет - увы. Это выстраданный подход. Когда авторизация перемешана с бизнес-логикой, система, как правило, уязвима. Если не сразу, то после пары релизов так точно.

В данном случае правильно создать два дерева URL:
/service/user/...
/service/admin/...
и настроить авторизацию фильтром по URL. В первом дереве не должно быть userid в параметрах, во втором - пожалуйста.

[newyorker]

ок, я повторю (перефразирую) вопрос.
У начальника (архитектора) требование что бы ни в каком из POST URL НИКОГДА не было никаких параметров. Все ID передавать через body.
Мне нужны аргументы что бы ему доказать что ИНОГДА это стоит использовать.
Или может проще согласиться и не стоит бодатья с упрямым начальником из за ерунды?

[helg]

URL оседают в логах веб-сервера, причем часто не одного - а всей цепочки. Доступ к логам, обычно, не так строго контролируется, как к базе пользователей. Возможно, начальник не хочет утечки каких-нибудь данных из базы через логи.

[newyorker]

К GET запросам у него претензий нет. Я так понял (но не уверен) что он хочет что бы все параметры были в одном месте. Если GET то в URL, если POST то в body.

[helg]

Запутано как-то всё. В первом сообщении вопрос про требование передачи user ID через сессию. Потом, что требование - не через сессию, а через тело POST. Полагаю, следует не гадать, а уточнить требование напрямую у начальника. А заодно и его обоснование.

[newyorker]

Главное его требование - передавать параметры "через одно и то же место "
Если GET - то URL
если POST - то в BODY, а в URL ни ни.

[kostik78]

Слушайте а Вам какой бенефит от того что Вы его переубедите кроме потраченных нервов ? Ну хочется ему так, пусть будет так. Может чел в армии служил и с тех пор приучен к "порядку"

[newyorker]

Да я уже к тому же мнению пришел. Просто было интересно мнение народа узнать

[Сабина]

Начальник требует что бы в POST запросах не было никаких id.
Т.е. если нужно например сохранить список preferences для определенного юзера, то и список preferences и user id требует передавать через сессию.
А мне кажется что нужно что бы url был
user/{id}/preferences

Прав я или не прав, и как его убедить? Или не принципиально?
Вообще, есть ли какие то стандарты качественных rest url?

Зависит наверное как у вас эти самые preferences хранятся и используются. А вот скажем почему совбственно не:

GET:
/preferences/12345

{ "id" : "12345",
"userId" : " abs678",
......

}

Соотвественно POST на /preferences

Насчет источников - очень уважаю эту книгу https://pages.apigee.com/rs/apigee/imag ... 012-03.pdf" onclick="window.open(this.href);return false;

[newyorker]

За книгу спасибо, почитаем

preferences это List внутри User обьекта.

[Сабина]

За книгу спасибо, почитаем

preferences это List внутри User обьекта.

В смысле list of settings? Или у одного юзера может быть несколько preferences ?

[newyorker]

У одного юзера могут быть разные preferences. Их список у него. Список хранятся не в отделньой коллекции, а в юзере.
Но это все не важно. Вопрос был о том как бороться и нужно ли бороться, если тебе запрещают использовать в POST запросах id в URL.

[Сабина]

У одного юзера могут быть разные preferences. Их список у него. Список хранятся не в отделньой коллекции, а в юзере.
Но это все не важно. Вопрос был о том как бороться и нужно ли бороться, если тебе запрещают использовать в POST запросах id в URL.

При таком раскладе я бы не делала отдельный endpoint для preferences. А preferences бы добавляла через HTTP PATCH к обьекту юзер.

Нужно ли бороться - это вообще вопрос политический, а не про best practices
Если ваш босс считает что id почему бы то ни было неуместны в сочетании с POST - пусть приведет источник таких best practices. Скажите что очень хотите ознакомится с его best practices поподробнее

[newyorker]

У одного юзера могут быть разные preferences. Их список у него. Список хранятся не в отделньой коллекции, а в юзере.
Но это все не важно. Вопрос был о том как бороться и нужно ли бороться, если тебе запрещают использовать в POST запросах id в URL.

При таком раскладе я бы не делала отдельный endpoint для preferences. А preferences бы добавляла через HTTP PATCH к обьекту юзер.

даже если нужно обновлять все preferences одной кучей одновременно?

[Сабина]

даже если нужно обновлять все preferences одной кучей одновременно?

Такое вроде только при создании эуккаунта из темплейта бывает? Например добавить default preferences. Добавляйте тогда сразу к обьекту юзер и через POST на /users добавляйте. Отдельный endpoint имеет смысл держать если преференсис живут сами по себе, а юзера сами по себе.
Если список преференсес составляет бОльшую часть user JSON обновлять можно через PUT.
Вытащить только preferences можно добавив partial response который еще для тонны всяких других задач полезный.
/users/abs123?fields=pereferences.*

Так чем он мотивирует то что id в POST нельзя?