RESTful URI завершающий sla sh или без завершающего слеша - PullRequest
Новая
       67

RESTful URI завершающий sla sh или без завершающего слеша

0 голосов
/ 01 мая 2020

Есть ли авторитетная позиция, которую я могу процитировать, когда дело доходит до конечного пункта sh в Restful URI? Один из Роя Филдинга был бы великолепен. В Интернете есть авторитетные мнения в обоих направлениях. Две позиции: Трейлинг sla sh указывает на ресурс, а его отсутствие - нет. Другим аргументом является то, что конечный sla sh не имеет значения semanti c. Что он? Пример: 

@GetMapping(path = "/users/")
  public List<User> getUsers() {
   ....
  }

  @GetMapping(path = "/users/{id}")
  public User getUser(@PathVariable String type)  {
   .....
  }

  @PutMapping(path = "/users/")
  public User updateUser(@RequestBody User user) {
   ....
  }

  @PostMapping(path = "/users/")
  public User createUser(@RequestBody User user) {
   ....
  }

  @DeleteMapping(path = "/users/{id}")
  public void deleteUser(@PathVariable Long id) {
   ....
  }

Должен ли быть удален конечный sla sh?

Ответы [ 2 ]

2 голосов
/ 01 мая 2020

Следующие URL: 

http://example/foo
http://example/foo/

НЕ являются одинаковыми URL. Кеши будут хранить их отдельно. Так что в этом смысле есть реальная разница. Нормализация URLS не приведет к их удалению.

Каждый URI (оканчивающийся на sla sh или нет) будет указывать на ресурс.

Насколько я знаю, нет конкретной рекомендации c использовать либо. Некоторые протоколы (например, WebDAV) используют его, чтобы предположить, что URL-адреса, заканчивающиеся на sla sh, подразумевают, что это коллекция.

Одним небольшим преимуществом окончания на sla * sh является то, что относительные URL-адреса внутри документа (которые не начинаются с sla sh) будет относиться к элементам в коллекции. Использование этого означает, что клиенты должны правильно разрешать относительные URL-адреса, что не всегда верно.

Большинство API, которые я видел, не заканчиваются косой чертой. Для некоторых людей, заканчивающихся на sla sh (и требующих этого) может быть удивительным поведением.

Нет официальных источников, потому что я не думаю, что они существуют. Я достаточно глубоко в стандартах, поэтому я достаточно уверен в этом.

1 голос
/ 01 мая 2020

Есть ли авторитетная позиция, которую я могу процитировать, когда дело доходит до конечного пункта sh в Restful URI?

Полномочная ссылка на URI: RF C 3986 . Раздел 3.3 включает производственное правило для сегментов. 

/users

Этот URI имеет путь /users, который включает в себя один сегмент: «пользователи» 

/users/

Этот URI имеет путь /users/ который включает в себя два сегмента: «пользователи» и пустой сегмент .

REST-клиенты должны обрабатывать /users и /users/ как два разных идентификатора - так, например, каждый из них будет иметь разные запись в кэше.

REST не предлагает какого-либо мнения о том, когда использовать какой-либо из них, или когда вы можете использовать оба. В том-то и дело, что орган (сервер) может назначать URI ресурсам любым удобным для него способом. Что касается всех остальных, то этот идентификатор непрозрачен.

Это означает, что используемые вами URI-написания должны соответствовать только местным соглашениям по орфографии.

Rails Routing from the Outside In описывает одно возможное соглашение, которое вы можете принять локально: «коллекция» использует орфографию одного сегмента, а члены коллекции используют два орфографических сегмента.

Использование этого соглашения означает, что /users к коллекции, и /users/, насколько я могу судить, не будет использоваться.

В домене, где для члена будет иметь смысл иметь пустой идентификатор, тогда мы могли бы ожидать, что член должен иметь идентификатор /users/.

...