RESTful дизайн URI

Для этих двух моделей, т.е. countries и states, я думаю, что следующие шаблоны Uri будут наиболее подходящими.

1. Все страны : api/country
2. Конкретная страна : api/country/{England}
3. Все штаты: api/country/{England}/State
4. Конкретное состояние: api/country/{England}/State/{Berkshire}

в приведенном выше примере значение внутри {} представляет переменные.

Это зависит от ваших вкусов. Оба варианта в порядке.

Для состояний можно создать новую конечную точку

api/states/name/Italy

Ваш подход с использованием имени в URL-адресе REST неверен. Название — это просто атрибут страны, а не подресурса, то есть вы не должны видеть его в URL-адресе. Однако можно было бы использовать его в качестве ключа, и в этом случае значение имени можно было бы использовать вместо идентификатора.

api/countries/Italy

Я думаю, что вы пытаетесь добиться, чтобы отфильтровать поля, т.е. получить только имена:

api/countries/Italy/states?fields=name

или, если вы заранее определили некоторые форматы

api/countries/Italy/states?format=onlyName

Как правильно представить поиск стран с атрибутами id или name?

tl;dr: Первый вариант вызывает путаницу. Если нужно выбрать, используйте строку запроса для поиска.

Что касается манифеста REST, логика URI — это всего лишь деталь реализации — единственное беспокойство заключается в том, что механизм доступа в этом месте не должен со временем ломаться. Содержимое может быть очищено или перемещено, но URI всегда должен заканчиваться на конечной точке службы, которая дает клиентам предварительный ответ, который они понимают и могут действовать (например, перенаправление 3 ** или повторное обнаружение гипермедиа клиентом).

Тем не менее, многие успешные и хорошо спроектированные API-интерфейсы пытаются раскрыть внутренне непротиворечивую логику, стремясь стать интуитивно понятными. Поэтому ваш первый пример api/countries/1/id на самом деле ПЛОХОЙ с точки зрения опыта разработчика и успеха на рынке, поскольку его использование сбивает с толку:

1. Глядя на URI, вы не имеете ни малейшего представления о том, что вы выполняете поиск (потенциально требовательный к ЦП/памяти) и НЕ извлекаете один ресурс
2. Многие общедоступные API-интерфейсы следуют логическому сопоставлению между иерархией ресурсов и открытыми URI, поэтому обычно ожидается, что api/countries/1/id извлекает {1} (что является бессмысленным запросом) или что api/countries/1/name дает {Italy}.

Таким образом, строка запроса является отличным вариантом, особенно для предложения функций поиска. Смысл слов виден ;)

api/countries?name=Italy 
api/countries?q=name(Ital*)              // same result
api/countries?q=isoCode=(IT)             // same result

--> api/countries/1/states               // list all states of Italy
    api/states?q=country/name(Italy)     // - same -
    api/states?q=country/id(1)           // - same -

Тело ответа на запрос можно ожидать, глядя только на URI, что приятно. Еще лучше: это помогает отличить ресурс от представления. «Вид» определяется в строке запроса, которую можно представить как линзу или фильтр, через который вы просматриваете фрагменты того, что в противном случае является одним и тем же ресурсом (коллекция ваших стран).

Этот шаблон так же хорош в этом отношении и также часто встречается:

api/countries/search/Italy
api/countries/search/name=Italy
api/countries/search/isoCode=IT,name=*aly

Причина выбора этого может быть связана с фактическими деталями реализации при создании вашего API - поскольку он отделяет прямой доступ к ресурсу от операции поиска - как требуемый ЦП/память для выполнения запроса, так и количество ответов и формат могут быть фундаментально разные.