Здравствуйте, brunoid, Вы писали:
B>работаю над структурой урл REST вебсервисов и думаю как сделать лучше.
B>например B>/users — вернет список пользователей B>/users/100 вернет конкретного пользователя
B>а как правильно сделать урл для получения информации об влогиненом пользователе ?
Если речь таки о RESTful (кошерный REST), то никак То есть вам необходимо получить на клиент идентификатор текущего пользователя и потом, по идентификатору, информацию по пользователю. Если необходимы какие-то ограничения доступа, то они реализуются на уровне конкретного вызова (в вашем примере /users/100) или фильтров в которые он попадает.
Если же речь о REST-style API и нет цели жестко придерживаться REST, как архитектурного подхода, то можно сделать что-то вроде /users/currentUser, /users/loggedIn или /users/logged-in.
Вариант помуторней, но который позволит разделить REST-часть и "часть типа REST" — это сделать отдельный "внутренний" АПИ для подобных вызовов, то есть что-то на подобии /internal/users/loggedIn. Тут для принятия решения надо знать всю задачу целиком.
Здравствуйте, silverwolf, Вы писали:
S>Здравствуйте, brunoid, Вы писали:
B>>работаю над структурой урл REST вебсервисов и думаю как сделать лучше.
B>>например B>>/users — вернет список пользователей B>>/users/100 вернет конкретного пользователя
B>>а как правильно сделать урл для получения информации об влогиненом пользователе ? S>Если речь таки о RESTful (кошерный REST), то никак То есть вам необходимо получить на клиент идентификатор текущего пользователя и потом, по идентификатору, информацию по пользователю. Если необходимы какие-то ограничения доступа, то они реализуются на уровне конкретного вызова (в вашем примере /users/100) или фильтров в которые он попадает. S>Если же речь о REST-style API и нет цели жестко придерживаться REST, как архитектурного подхода, то можно сделать что-то вроде /users/currentUser, /users/loggedIn или /users/logged-in. S>Вариант помуторней, но который позволит разделить REST-часть и "часть типа REST" — это сделать отдельный "внутренний" АПИ для подобных вызовов, то есть что-то на подобии /internal/users/loggedIn. Тут для принятия решения надо знать всю задачу целиком.
спасибо ! реализую вот такой урл /users/currentUser
сам сервис /user/* у меня засекьюрен при помощи oauth2 и таким образом при наличии accessToken сервис вернет либо пользователя которому этот токен выдан либо ошибку авторизации.
Здравствуйте, brunoid, Вы писали:
B>сам сервис /user/* у меня засекьюрен при помощи oauth2 и таким образом при наличии accessToken сервис вернет либо пользователя которому этот токен выдан либо ошибку авторизации.
Не забудьте "вернуть пользователя" при помощи 302 Found с location: /users/xxxxx.
Это позволит клиенту следующим ходом взять данные пользователя из кэша.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
S>Не забудьте "вернуть пользователя" при помощи 302 Found с location: /users/xxxxx.
А мне вот интересно, насколько много коллективов следуют всем концепциям, предусмотренным, скажем, RFC 2616?
Пишите, люди, рассказывайте...
Например, учет версий для оптимистической блокировки можно сделать кустарно, введя какое-то поле version в передаваемом состоянии. А можно — через Etag и прочее, что даст определенные преимущества. А там же довольно много нюансов — скажем, если мы внесли свои коррективы в переданное в PUT состояние, мы не имеем права на него возвращать Etag.
Ну или можно сделать создание ресурса — без указания конкретного id — через PUT, а не POST, что вроде бы тоже нарушает конвенцию.
Можно url называть file/{id}/upload, file/{id}/download, file/{id}/delete, и все их запрашивать через GET.
Мой вопрос сводится к чему... насколько вообще важно знать "настоящие", правильные, "by design" подходы к созданию REST API, или можно делать как бог на душу положит и никто за это на тебя косо смотреть не будет? А то может "по мануалам" это делают в одной конторе из сотни...
Slicer
Специалист — это варвар, невежество которого не всесторонне :)
Здравствуйте, Slicer [Mirkwood], Вы писали:
SM>Ну или можно сделать создание ресурса — без указания конкретного id — через PUT, а не POST, что вроде бы тоже нарушает конвенцию.
Я тут не так давно спрашивал об этом и мне посоветовали
более удачный вариант — создавать пустую запись через POST, после чего обновлять её уже через PUT.
SM>Можно url называть file/{id}/upload, file/{id}/download, file/{id}/delete, и все их запрашивать через GET.
GET неправильно использовать для этих целей. Запрос GET не должен изменять состояние данных.
Результаты GET-запросов могут кэшироваться и одно из последствий такого подхода будет то, что повторные запросы просто не будут отправляться — какая-нибудь промежуточная прокся или кэш приложения будут просто возвращать готовое значение на такой вот {id}/upload.
SM>насколько вообще важно знать "настоящие", правильные, "by design" подходы к созданию REST API, или можно делать как бог на душу положит и никто за это на тебя косо смотреть не будет?
Неправильные подходы чреваты очень скорыми проблемами. Это просто к вопросу об удобности любого API, в т.ч. и REST API. Если сделать криво и косо, то это гарантированно принесёт баги и тихую ненависть пользователей этого API.
Здравствуйте, Artem Korneev, Вы писали:
AK>GET неправильно использовать для этих целей. Запрос GET не должен изменять состояние данных. AK>Результаты GET-запросов могут кэшироваться и одно из последствий такого подхода будет то, что повторные запросы просто не будут отправляться — какая-нибудь промежуточная прокся или кэш приложения будут просто возвращать готовое значение на такой вот {id}/upload.
Ну, не скажите. Кэш приложения вы же сами и контролируете. Данные-то у вас все равно меняются, значит, должен быть способ не кешировать запросы в зависимости от каких-то условий. Прокси тоже не должен кешировать все подряд, либо это должно какими-то хедерами контролироваться (правильная простановка которых, кстати, обычно в начальных примерах по REST не описывается), т.е. тоже вполне управляемо. Так что это, по-моему, просто страшилки, за которыми по факту стоит общий настрой "делать как задумано конвенцией". Что, я считаю, неплохо, если б не тот печальный факт, что отнюдь не все ее придерживаются.
Вот я и хотел узнать, как много людей придерживаются. Но пока, кроме вас, никто не ответил ничего =)
Slicer
Специалист — это варвар, невежество которого не всесторонне :)
То есть вам необходимо получить на клиент идентификатор текущего пользователя и потом, по идентификатору, информацию по пользователю. Если необходимы какие-то ограничения доступа, то они реализуются на уровне конкретного вызова (в вашем примере /users/100) или фильтров в которые он попадает.
