2014-02-07 2 views
1

Как выбрать использование строковых или целых идентификаторов в URL-адресах RESTful. Например, я вижу, что API Github использует строки в некоторых случаях, например.Использование строковых и целых идентификаторов в URL-адресах RESTful

GET https://api.github.com/repos/nareshbhatia/git-explorer 
=> get a repository whose id is "git-explorer" 

тогда как целые числа в других

GET https://api.github.com/repos/octocat/Hello-World/issues/1347 
=> get an issue whose id is 1347 

Я понимаю, что это более естественно определить хранилище по его имени и вопрос по его номеру, но с точки зрения реализации строка идентификатора создает несколько проблем , Должен ли первичный ключ для таблицы репозитория быть именем? Но строка, как правило, является плохим выбором для первичного ключа. Итак, как насчет целого суррогатного ключа и сделайте имя уникальным столбцом. Но это означает, что всякий раз, когда у меня есть ссылка на репозиторий (целое число), и мне нужно создать URL-адрес для него, я вынужден сделать соединение с таблицей репозитория - просто чтобы получить его имя.

Чтобы уточнить, предположим, что я создаю JSON для проблемы, и мне нужно включить ссылку в репозиторий, мне нужно соединение с таблицей репозитория, чтобы создать ссылку вроде /repos/nareshbhatia/git-explorer вместо простой ссылки с целым числом ссылка как /repos/nareshbhatia/10

ответ

0

Я не уверен, что согласен с утверждением, что строки являются плохим выбором для ПК. Конечно, если вы используете естественный ключ, шансы хорошие, вы будете использовать строки. Многие люди предпочитают целые числа, потому что они более компактны и повышают производительность по индексам, но производительность не должна быть вашим единственным соображением, и есть преимущества для естественных ключей. Достаточно о базе данных.

Когда вы начинаете говорить об URI, действительно нет заметного преимущества в производительности для более коротких URL-адресов, поэтому целые числа не имеют производительности как край над строками. String также имеет преимущество SEO над целыми числами в URI. Эти соображения могут привести к созданию базы данных с целыми первичными ключами, но используйте строки в качестве URI в ваших спокойных конечных точках.

+0

Я сам был склонен идти за струнами как ПК, но мнения в сети кажутся 50-50. Также я думал, что если такие большие ключи отображаются как внешние ключи в связанных таблицах, это не кажется правильным. Вот почему мысль о суррогатном ключе как ПК. Кстати, действительно ли люди считают преимущество SEO для API RESTful? Я подумал, что это только для страниц. (конечно, я согласен с тем, что значимый/читаемый URI, даже в случае REStful API, является намного предпочтительнее.) – Naresh

 Смежные вопросы

  • Нет связанных вопросов^_^