Блог

У меня есть следующие конечные точки 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?

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 и «предстоящие»это зарезервированное слово… все, что вам нравится).