RESTful API URI Design

Ответ 1

Второй пример выглядит хорошо для меня. URL-адреса описывают ресурсы и используются правильные HTTP-глаголы.

Совершенно прекрасно иметь несколько URL-адресов, указывающих на один и тот же ресурс, если это имеет смысл. Но что более важно, убедитесь, что ресурсы содержат элементы <link />, которые соединяют шоу с сетями, эпизоды и т.д.

Ответ 2

URI - это "любая информация, которой может быть присвоено имя"

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

Вопрос, который приходит на ум при попытке угадать ваш домен, действительно ли "шоу" действительно зависит от "сети"?

Что такое сеть в вашем домене? и какова связь между шоу и сетью? Это просто кто-то, кто передал шоу? или это больше связано с производственной информацией?

Я считаю, что ваш пример 2 намного лучше подходит.

Ответ 3

Учитывая, что у вас есть отношения "один ко многим" в следующей иерархии:

network --> shows --> episodes

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

Network id  show_id episode_id
    1         1        1
    1         2        1
    1         1        2

Первый проект, который является подробным, предоставит достаточную информацию в HTTP-запросе для извлечения данных: /networks/1/shows/1/episodes/1

Вторая конструкция наоборот:

/episodes/1 

Во втором дизайне стороне сервера не известно, хотите ли вы иметь в виду строку 1 или строку 2 из ваших данных.

Чтобы ответить на ваш вопрос:

• ИМХО 2-й дизайн не может быть действительным дизайном REST для вашего примера. обходным путем может быть передача параметров запроса

• Я думаю, что дизайн 1 является самодостаточным

ОБНОВЛЕНИЕ: проигнорируйте мой ответ выше

• 2-й дизайн - это действительный дизайн REST для вашего примера
• Только наличие дизайна 2 также должно быть достаточным

Дополнительно:

/networks
/networks/{id}

/shows
/shows/{id}

/episodes
/episodes/{id}

должно быть достаточное количество URL-адресов REST

или, другими словами, следующие URL-адреса будут избыточными:

/networks/{network_id} [GET,PUT]
/networks/{network_id}/shows [GET,POST]

/shows/{id}/episodes [GET,POST]

Ответ 4

Я думаю, что мы должны поддерживать URL-адрес API REST как можно проще.

например. https://www.yoursite.com/api/xml/1.0/

Здесь я беру пример XML API для версии 1.0. Не забудьте использовать версии API для будущих обновлений.

Вы можете проверить метод, который запрашивает клиент.

e.g. tag

<method>getEpisodes</method>

Ответ 5

Реальный вопрос здесь: ваш второй пример соответствует стандарту URI? В стандарте URI указано, что путь содержит иерархическую часть, а запрос содержит неиерархическую часть, но afaik. он ничего не говорит о том, как создать структуру URI в вашей ситуации. У ограничений единого интерфейса REST есть раздел HATEOAS, что означает, что вы должны отправлять обратные ссылки в свою ситуацию, что указывает на ресурсы верхнего и нижнего уровня. Вы должны аннотировать эти ссылки с метаданными, которые могут быть обработаны клиентом, поэтому он будет знать, что такое ссылка. Поэтому на практике структура URI не имеет большого значения...

GET /shows/123

{
    "label": "The actual show",
    "_embedded": {
        "episodes": [
            {
                "label":  "The first episode of the actual show",
                "_embedded": {
                    "associations": [
                        //...
                    ]
                },
                "_links": {
                    "self": {
                        "label": "Link to the first episode of the actual show",
                        "href": "/episodes/12345"
                    },
                    "first": {
                        "href": "/episodes/12345"
                    },
                    "duplicate": {
                        "href": "/networks/3/shows/123/episodes/12345"
                    },
                    "up": {
                        "label": "Link to the actual show",
                        "href": "/shows/123"
                    },
                    "next": {
                        "label": "Link to the next episode of the actual show"
                        "href": "/episodes/12346"
                    },
                    "previous": null,
                    "last": {
                        "href": "/episodes/12350"
                    }
                }
            }//,
            //...
        ]
    },
    "_links": {
        "self": {
            "label": "Link to the actual show",
            "href": "/shows/123"
        },
        "duplicate": {
            "href": "/networks/3/shows/123"
        },
        "up": {
            "label": "Link to the actual network",
            "href": "/networks/3"
        },
        "collection": {
            "label": "Link to the network tree",
            "href": "/networks"
        },
        "next": {
            "label": "Link to the next show in the actual network",
            "href": "/shows/124"
        },
        "previous": {
            "label": "Link to the previous show in the actual network",
            "href": "/shows/122"
        }
    }
}

Теперь это только что-то очень бета в HAL + JSON с отношениями ссылок IANA, но вы можете использовать JSON-LD с лексикой RDF (например, schema.org + hydra). Этот пример касается только иерархии (вверх, сначала, следующей, предыдущей, последней, коллекции, элемента и т.д.), Но вы должны добавить больше метаданных, например. который связывает точки с сетью, которая должна быть показана, и которая к эпизоду и т.д. Итак, ваши клиенты будут знать из метаданных, о чем идет речь, и, например, они могут использовать ссылки для автоматического перехода. Вот как работает REST. Таким образом, структура URI не имеет особого значения для клиента. (Вы также можете использовать компактные URI и URI-шаблоны, если хотите, чтобы ваш ответ был более компактным.)

Ответ 6

Я думаю, что второй вариант - Ok, но если вы хотите проверить отношения, я бы рассмотрел первый вариант. Например, когда вы получаете эпизод с другой сетью, это может означать, что эпизод был модифицирован до вашего запроса, поэтому, возможно, вам нужно ответить с помощью 422, то же самое для других служб. При этом вы можете быть уверены, что объект, с которым вы хотите работать, включает его родителя.

PD: Извините за мой английский.