CODEWITHSUNDEEP
apiresturl
SNO
SNO

Reputation: 866

REST URL handling with DTOs

In my project I have a model with different DTOs:

public class Employee{
    public Guid Id {get; set;}
    public string Name {get; set;}

    public IEnumerable<Cookie> Cookies {get; set;}
}

public class EmployeeIndex :Dto{
    public Guid Key{get; set;}
    public string Value {get; set;}
}

public class Cookie {
    public Guid Id {get; set;}
    public string Secret {get; set;}
}

public class CookiePublic :Dto{
    public Guid Id{get; set;}
}

Now I would like to keep my API as clean as possible. So I have the following Routes:

POST   /employees
GET    /employees
GET    /employees/index //--> Conflict (should return list of EmployeeIndex
GET    /employees/:id
PUT    /employees/:id
DELETE /employees/:id
GET    /employees/:id/cookies // --> returns List of Cookies
GET    /employees/:id/cookies/:cookieId
GET    /employees/:id/coookies/public // --> Conflict (should return list of CookiePublic)

But now I need a route for returning also the CookiePublic-DTO. Where can I put that url respectively how does the routes should look like? Or how would the route should look like to return the employee-index-Dto?

Because /employees/:id/cookies/public and employees/index results in a duplicate url conflict.

How can this get solved in REST?

Upvotes: 1

Views: 51

Answers (1)

VoiceOfUnreason
VoiceOfUnreason

Reputation: 57229

REST doesn't care what spelling conventions you use for your resource identifiers.

It also doesn't really have any sense of "conflict" as you describe here. The fact that there is ambiguity about the identify of your conflicting resources is an artifact of your routing implementation, not REST.

In other words

/employees/index
/employees/12345
/employees/67890

as far as REST is concerned, these are three different resources. The fact that they want to be implemented via two routes is an implementation detail.

From a REST perspective, there's no particular reason that the hierarchy of path segments needs to match the domain hierarchy (the "resource model" is not the "domain model" is not the "data model").

So you could consider

/employees/12345
/index/employees

/employees/12345/cookies
/cookies/123
/public-cookies/123

The machines absolutely don't care whether the structure of the URI matches the domain semantics. They care a little bit about some general purpose things (the ability to use relative references to compute other resource identifiers, the ability to use general purpose URI templates to compute other resource identifiers, the ability to use web forms as URI templates, etc).

So we use the extra degrees of freedom allowed by the machines indifference to choose a design that makes life easier for the humans we care about (customers looking at a browser history, operators reviewing an access log, technical writers trying to document the API, etc).

Upvotes: 1

Related Questions