Ресурсы в APIRestful
Я читал несколько вещей об API, но кое-что мне неясно по поводу того, как структурировать resources. Приведу простой, но наглядный пример. Мы представляем, что у нас есть такие отношения:
|Clients| (1:1) ------<>----- (0:M) |Orders| (1:1) ------<>------ (1:1) |Statuses|
У клиента может быть ноль или много заказов, и каждый заказ имеет статус.
Вопрос возникает при создании ресурсов, ресурсы, которые понятны, следующие:
GET /clients (get a list)
GET /clients/10 (get detail of one client)
POST /clients (create a client passing data by BODY)
(Могло быть больше похоже на PUT, но для упрощения примера я упрощаю.)
Вопрос в том, чтобы получить Заказы от Клиент, такого как resource?
GET /clientes/10/orders
Или на месте:
GET /orders?id_cliente=10
То же самое, чтобы получить детализацию Заказ, на что это было бы похоже?
GET /clientes/10/orders/10
Или было бы просто иметь смысл сделать это (что также показало бы информацию о Состояние, которая у вас есть):
GET /orders/10
Или когда вы хотите удалить заказ:
DELETE /orders/10
или же
DELETE /clientes/10/orders/10
И чтобы создать Заказ, должен ли Клиент всегда существовать или могут быть созданы Заказ и Клиент одновременно со следующим ресурсом? Например, Клиент, не зарегистрированный при совершении покупки, поместит Заказ и зарегистрируется одновременно)
POST /orders
Передача данных Клиент в BODY ему как данные Заказ. Сначала будет создан Клиент, а затем Заказ.
Если есть кто-нибудь, кто знает, как будут выглядеть все допустимые ресурсы образца отношения, было бы хорошо поделиться ими. Я не хочу вдаваться в темы разбиения на страницы или другие темы, которые также важны для API. Только в плане ресурсов.
Ответы 1
Чтобы устранить путаницу, вы можете просто задать себе следующие вопросы.
- Есть ли у моего ресурса уникальный идентификатор ресурса? - Не должно быть нескольких элементов ресурса, указывающих на один и тот же ресурс.
- Может ли дочерний ресурс существовать без родителя? - Если он может существовать, то его не следует рассматривать как дочерний ресурс, а следует рассматривать как отдельные ресурсы.
В вашем случае, согласно вышеизложенному, ясно, что ресурс клиенты является родительским для ресурса заказы. Итак, конечные точки API должны быть,
/clients (GET) - get all clients
/clients/$client_id (GET) - get a client
/clients/$client_id/orders (GET) - get all orders of the particular client
/clients/$client_id/orders (POST) - create new order for the client
/clients/$client_id/orders/$order_id (PUT) - Modify the particular order for the client
/clients/$client_id/orders/$order_id (DELETE) - Delete the particular order for the client
И что касается вашего последнего вопроса о создании родительского ресурса, когда дочерний ресурс создает API-интерфейс, Обратитесь к мой ответ
Примечание. Сортировка, фильтрация, ограничения и разбиение на страницы могут поддерживаться с помощью параметров запроса в ваших API.
Но можно ли иметь ресурс / заказы, которые получают все заказы (кем бы они ни были)? Или это будет плохой способ сделать это?
Если такие API-интерфейсы разрешены в зависимости от того, кем они являются, поможет ли это клиентам, использующим ваш API? Кроме того, вам следует дважды подумать о том, чтобы кто-либо мог получить доступ к чужим ресурсам.
REST.