0

If entity (e.g person) has data that has to be presented in different representations:

I have a big profile that has different representations but for a small example:

representations1:

GET /profiles/{id}/activity/projection1

returns:

{"actions":["add", "delete", "add"], "dates":[1499865456, 1499861544, 1499863655]}

representations2:

GET /profiles/{id}/activity/projection2

returns:

{add_at:[1499865456, 1499863655], delete_at:[1499861544]}

So the question: how to design such cases? I have some ideas but don't know which one is better

GET /profiles/{id}/activity/projection1
GET /profiles/{id}/activity/projections/1
GET /profiles/{id}/activities/projection1
GET /profiles/{id}/activities/projections/1
GET /profiles/{id}/activity-actions and GET /profiles/{id}/activity-timestamps

I found only one same question Different RESTful representations of the same resource but it is about filtering data in response not about change model

Ivan
  • 462
  • 3
  • 13

1 Answers1

0

A couple things to keep in mind

As far as REST is concerned, two things with different identifiers (URI) are different resources. The fact that they have the same source of truth is an implementation detail.

In designing a REST api, your resources are integration points. The representations of your resources will depend on the state of your model at any given time.

For instance, if I look up Clayton Kershaw at Baseball Reference, I am probably directed to this resource

http://www.baseball-reference.com/players/k/kershcl01.shtml

But if I ask to see his "2014 splits", then I'll be directed to this resource instead.

http://www.baseball-reference.com/players/split.fcgi?id=kershcl01&year=2014&t=p

There's no particular reason that every resource identifier related to kershcl01 has to be under the same root in the hierarchy.

You may want to review Cool URIs don't change; stable URI over time is a good goal for a design, in which case you'll want to make sure that temporary implementation details don't leak into the URI space.

Jim Webber's observation was that REST resources are part of your integration domain; "Resources adapt your domain model for the web."

So your design guidance should probably come from asking what properties are important to your consumers, and what constraints will ensure that those properties are present (outside in), rather than starting from your (current) implementation.

VoiceOfUnreason
  • 52,766
  • 5
  • 49
  • 91