Правильное руководство по дизайну Restful API - PullRequest
0 голосов
/ 07 апреля 2020

Я создаю Restful API перед созданием внутреннего сервера. Это небольшой сервис в Instagram, и я хочу знать, что мой спокойный дизайн соответствует принципам REST.

Аутентификация

  • Создать учетную запись: POST / auth / user
  • Удалить учетную запись: DELETE / auth / user
  • Вход в систему: POST / auth / session
  • Выход: DELETE / auth / session

Пост

  • Загрузка фида: GET / posts
  • Создать пост: POST / posts
  • Читать пост: GET / posts /: post_id
  • Удалить сообщение: DELETE / posts /: post_id
  • Читать комментарии: GET / posts /: post_id / comments
  • Создать комментарий: POST / posts /: post_id / comments
  • Удалить комментарий: DELETE / posts /: post_id / comments /: comment_id
  • Создать лайк: POST / posts /: post_id / likes
  • Читать лайки: GET / posts /: post_id / likes
  • Удалить как: DELETE / posts /: post_id / likes /: like_id

Follow

  • Читать следующее: GET / followings /: user_id
  • Creat e следующее: POST / followings /: user_id
  • Удалить следующее: DELETE / followings /: user_id
  • Чтение подписчиков: GET / подписчики /: user_id

Активность

  • Чтение действий: GET / деятельность

Поиск

  • Читать поиск: GET / фильтр /: search_term

Исследовать

  • Читать исследовать: GET / подобные

Я новичок в Restful API дизайн, поэтому я хочу совет или модификацию для моего дизайна. Это соответствует принципам?

1 Ответ

0 голосов
/ 07 апреля 2020

Я новичок в дизайне Restful API, поэтому я хочу совет или модификацию для моего дизайна. Это соответствует принципам?

REST не волнует, какое написание используется для идентификаторов ресурсов. Неважно, как вы проектируете свои ресурсы. Его интересует гипермедиа, кеширование и использование стандартизированных определений вещей, чтобы мы могли использовать компоненты общего назначения для достижения полезной работы.

GET /activities
GET /95d9f08a-fb79-4a18-a630-b2e31ad7039a

Оба эти URI штраф ; компоненты общего назначения будут работать правильно в любом случае, потому что машины не заботятся о написании (при условии, что написанное вами написание соответствует RF C 3986 ) - идентификатор является идентификатором, и машины не пытаются извлечь из них какую-либо семантическую c информацию. Это означает, что ваш сервер, действуя от своего имени, может выбирать любые варианты написания, которые вы хотите.

Другими словами, мы суетимся над написанием URI по тем же причинам, по которым мы суетимся над написанием имен переменных - сделать вещи проще для других людей. Таким образом, любое внутренне согласованное соглашение об орфографии является отлично , точно так же, как любое согласованное соглашение об именовании переменных / функций / классов в порядке.

Использование GET для всех ваших операций чтения и POST со всеми вашими записями все в порядке - сеть была катастрофически успешной, в конце концов. POST несколько интересен тем, что вы хотите убедиться, что понимаете последствия для аннулирования кэша .

...