REST URL命名约定/items/{id}与/items?id = {id} [英] REST URL naming convention /items/{id} vs /items?id={id}

问题描述

我知道在MVC模式和REST服务中，通常使用/items/{id}这样的URI，但是在URI中使用查询参数有什么不好的事情呢?

I understand that in MVC pattern and in REST services it is common to use URIs like /items/{id} but what is bad thing about using query parameters in the URI?

GET /items/{id}与GET /items?id={id}

此外，可以说一个实体具有指向某些相关(例如父实体)实体的'referenceId'字段，我需要创建REST服务以获取父实体的所有项目，这种方法更好:

Further, lets say an entity has 'referenceId' field that points to some related (say parent) entity, and I need to create REST service to get all items for parent entity, which way is better:

GET(POST) /items/parent/{parentId} 

或

GET(POST) /items?parent={parentId}

对于能帮助我解决有关为REST服务构建URL的主观问题的见解将不胜感激.

Will be grateful for insights that would help to resolve my subjective issues on constructing URLs for REST services.

推荐答案

我将使用以下方案.

/items/id

这唯一地标识ID为id的项目资源.我们没有使用参数作为唯一寻址此资源的参数(与其他选项一样).正如 miguelcobain建议.

This uniquely addresses a resource of items with id id. We are not using parameters as a parameter to uniquely address this resource (as is the case with the other option). Just as miguelcobain suggests.

/parent/id/items

此处id是一个ID，用于唯一地寻址父级资源，并从这些资源中收集/检索其引用的项.从您在问题中所说的看来，父级似乎引用了多个项目，例如容器或集合.

Here id is an id to uniquely address a resource of parent and from those we collect/retrieve the items it references. From what you have said in the question it seems that parent references multiple items, like a container or collection.

我为此使用的约定是缩小从左到右的范围.因此，如果项目可能是active或inactive.因此，项目的属性或属性为active或inactive.对此，我缩小了以下方案:

The convention I use for this is to narrow down the scope going from left to right. Therefore in case items could be active or inactive. Thusly items have a property or attribute to be active or inactive. Narrowing down on this I get the following scheme:

/items/active
/parent/id/active

这篇关于REST URL命名约定/items/{id}与/items?id = {id}的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！