aman
aman

Reputation: 127

A read-only derived REST resource?

I am creating a new service in which I need to support tagging on two entities. Can I create /tags as a top level REST resource which supports only following calls:

GET    /tags

GET    /tags/{tagName}

To apply tags, we use following calls:

PATCH    /entity1/{entity_1_Name}

PATCH    /entity2/{entity_2_Name}

So whenever a tag is applied to an entity, subsequent calls to GET /tags will show that tag. I am planning to do this, as this does not require me to store the tags independently in my data-store.

Is this a good idea?

Upvotes: 1

Views: 154

Answers (1)

Artem
Artem

Reputation: 2314

Can I create /tags as a top level REST resource

Yes, you can. That sounds meaningful if tag is an independent entity and api response will contain only tag_name and other tag-related information only. It doesn't matter if your api has a database or web.config under the covers or it deals with hardcoded list of values. Your API interface hides this fact anyway and user will never know the details of implementation. It is okay to have a readonly entity.

whenever a tag is applied to an entity, subsequent calls to GET /tags will show that tag

I'd expect that your resource model for GET /entity2/{entity_2_Name} will have a tags field:

class Entity2
{
    string entity_name;
    ...
    string[] tags
}

As an alternative you can fetch all data via two calls:

GET /entity2/{entity_2_Name} //has no tags array in a response

GET /entity2/{entity_2_Name}/tags

The resource /entity2/{entity_2_Name}/tags should return tags which are assigned to this concrete entity2 instance

Upvotes: 1

Related Questions