Допустим, у меня есть объекты иного типа House и Car. Теперь я хочу добавить комментарии.Дизайн JSON-API
Что лучше? Наличие оконечные:
/api/house/:houseId/comments
/api/car/:carId/comments
Или общее апи для комментариев, как:
/api/comments/:generalId
для меня тип продукта деталь реализации. Чтобы быть REST-стиле Я хотел бы создать API с
/апи/продукта/[ProductID]
Эта конечная точка будет SUPORT GET (получить данный продукт), POST (обновление данного продукта), DELETE
/апи/продукта/
Эта конечная точка будет поддерживать GET (получить все продукты), PUT (создать новый продукт)
/api/product/[productID]/комментарии/[комментарийID]
Эта конечная точка будет поддерживать GET (получить данный комментарий для данного продукта) и POST (обновить данный комментарий), DELETE (удалить данные комментарии). В этом случае commentID может быть уникальным только для каждого ресурса, а не во всем мире.
/апи/продукт/[ProductID]/комментарии
Эта конечная точка будет поддерживать GET (получить все комментарии для продукта) и PUT (создать новый комментарий), DELETE (удалить все комментарии для продукта)
апи/комментарии/[CommentID]
Этот ресурс (с операции GET, POST, DELETE) также хорошо. Но для этого нужен глобальный уникальный комментарий. Не стесняйтесь раскрывать такую конечную точку, если вам нужно управлять отдельными комментариями, не зная productId. Это не нарушает REST.
В этом проекте API у нас есть отдельные ресурсы для каждого продукта и комментарии. У нас также есть ресурс для всех продуктов и ресурс для всех комментариев для данного продукта. Каждый из этих ресурсов может поддерживать GET, POST, PUT, DELETE. Вы можете ommit некоторые операции (например, не подвергать POST на /api/product/[productID]/comments/[commentID], когда вы не хотите, чтобы поддерживать редактирование комментариев
Edit:.., Как предложено в комментариях @lospejos вы можете использовать формы множественного числа (продукты, комментарии) В любом случае , ваш API будет REST-стилем, причем каждый пост/комментарий будет отдельным ресурсом.
Я согласен с тем, что я использовал бы множественные числа для объектов: '/ products','/comments' и т. Д. В каждой конечной точке – lospejos
Извините, я не был достаточно ясен на вопрос. Продукты не могут быть только одной конечной точкой. Его больше похоже на/api/house и/api/car. Я редактирую вопрос, чтобы сделать это более ясным. – Stefan
ОК, поэтому make/api/house/[id] и/api/car/id. Или кодируйте тип продукта в id, например /api/house.[house-id] /api/car.[car-id]/. В любом случае, чтобы быть RESULL, вам нужен уникальный идентификатор rerource (URL) для каждого отдельного ресурса. –
Без особого формального образования в дизайне API я бы сказал, что первое лучше, потому что оно более структурировано - я вижу в нем разницу между имея productA.comments/productB.com по сравнению с комментариями большого массива [] –
, моя проблема заключалась в том, что в коде API я получаю зависимости от комментариев.model от каждого объекта.поэтому читаемость API стоит больше, чем структура API-кода? – Stefan