dthree
dthree

Reputation: 20730

REST solutions when not strictly referring to an actual resource

Take a simple table person:

CREATE TABLE person
(
  id bigint,
  name nvarchar(128),
  age int
)

You can represent this in a REST interface:

GET /person
GET /person/5
PUT /person
POST /person/5
PATCH /person/5
DELETE /person/5

This interface would expect 2 parameters:

{ 
  name: 'Joe',
  age: 16,
}

You could then define an API that would expect those two parameters, and even make the age optional.

However, suppose you wanted to define a model on the client side that wanted to do fancy things with this person table, such as pulling all teenagers, how would you best represent this?

I suppose I could do something this, only support GET, and then arbitrarily require different parameters which matched the query needs:

GET /person/teenager

However, I don't know that this would properly meet all use cases. For example, I believe REST urls should only have nouns, and I am not sure how to put something like this into noun form:

GET /person/by-age

Any ideas / references / suggestions?

Upvotes: 0

Views: 34

Answers (1)

Jason Desrosiers
Jason Desrosiers

Reputation: 24409

The most common way to constrain your person listing results is to use query parameters. You can define your query parameters in any way that is useful for your API. One example might be GET /person?age=13..20 to get only teenagers. Another example might be GET /person/?filter=age>=13,age<20.

Upvotes: 2

Related Questions