#rest #api-design
#rest #api-дизайн
Вопрос:
У меня есть следующие конечные точки REST, и я не уверен, соответствует ли он лучшим практикам. Разные сайты говорят разные вещи. Поэтому хотел проверить здесь.
GET - /api/v1/service/prj --> To get projects for the logged in user
GET - /api/v1/service/prj/upcoming --> To get upcoming projects for the logged in user
GET - /api/v1/service/prj/upcoming/all --> To get all projects for admin user
GET - /api/v1/service/prj/{prj_id} --> To get all projects for admin user
GET - /api/v1/service/prj/usr/{user_id}
GET - /api/v1/service/prj/usr/all
GET - /api/v1/service/prj/usr/{user_id}/upcoming
GET - /api/v1/service/prj/usr/{user_id}/open
GET - /api/v1/service/prj/details/{prj_id}
Здесь проблема заключается в,
GET — / api/ v1/service/prj / предстоящий
ПОЛУЧИТЬ — /api/v1/service/prj/{prj_id}
В Spring router, если я сначала размещу 2-й, /prj/{prj_id} будет сопоставлен с /prj/предстоящим. Итак, пытаюсь понять наилучшую практику.
Я думал о другом маршруте, например,
вместо /prj / компиляции используйте prj-предстоящий. Пожалуйста, помогите мне с лучшей практикой здесь.
Кроме того, используйте подчеркивание для параметра пути и параметра запроса.
Например, {prj_id} . Но я вижу некоторые ссылки с использованием prjId. Какова наилучшая практика использования параметров path и query?
Ответ №1:
REST не волнует, какие соглашения о правописании вы используете для своих идентификаторов ресурсов, если эти соглашения соответствуют правилам производства, определенным в RFC 3986.
В частности: с точки зрения компонента REST идентификаторы семантически непрозрачны, вы можете использовать любой идентификатор для ссылки на любой документ, который вам нравится.
GET - /api/v1/service/prj/upcoming
GET - /api/v1/service/prj/{prj_id}
Это проблема маршрутизации; клиентам все равно, но, как вы обнаружили, ваша реализация маршрутизации действительно важна.
Что вы можете сделать?
- Вы можете изменить свои соглашения о правописании — и это нормально
- Вы можете изменить свою реализацию маршрутизации — и это нормально
- Вы можете написать свою собственную логику для устранения двусмысленности — и это нормально
То, что вы не можете сделать в любой разумной системе, — это разрешить одному идентификатору ссылаться на два разных ресурса.
Таким образом, вы можете иметь {prj_id} и предстоящие в одном и том же месте, если в вашей внутренней схеме ясно, что «предстоящие» никогда не являются допустимым prj_id (будь то потому, что prj_id всегда является числом или всегда UUID, или потому, что зарезервированные слова не разрешены как prj_id и «предстоящие»это зарезервированное слово… все, что вам нравится).