RESTful URI – Handling Many-to-Many Relationships

database-designrestweb services

I am having confusion while choosing a database relation and Restful URI for application I am developing.

I am making a simple library application with following requirements.

Book can belong to many categories e.g Physics book belong to Textbook and Science Category. We can say book have many categories/labels/tags.
Viewing books in one category.
Viewing a book's all categories.
Searching book using categories or book information.
Book CRUD operations
Label CRUD operations

Considering all these requirements I choose ManyToMany relation between Books and Labels. I have implemented it using Hibernate Framework.
Now when it came to designing Restful Services for this its getting very confusing.It makes me question table relationship choice as well.

Restful uri made yet.

/books

/books/{bookid}

/labels

/labels/{labelid}

But when I want to get a list of labels against a book, or a list of books against a label. How to map them using Restful URI. I can think of this

/book/{bookid}/labels

But considering this,how to map getting a list of books against one label

I want to know whether my choice of table relationship is right and if yes, how to design restful uri against it. And if no, please correct me and put a light on this scenario. Thanks

Best Answer

Regarding the table, if a book can have many labels and a label many books (sounds quite reasonable) then that's a many to many relationship.

In case of REST the many to many relation is in fact a bit confusing since we talk about resources and with the URI being a unique identifier it seems weird to be able to access one and the same resource from two directions.

Maybe the best way is to see a resource not only as a simple thing (book, label) but also as a specific set of things (books, labels of a book). You often have nested resources anyway and the many to many is just one variant where two different ways to view these sets make sense (assuming that your users will want to access in both variants which seems likely for your use case).

So in fact you would have two ways to access this:

/book/{book_id}/labels

and

/label/{label_id}/books

You will most likely have similar approaches for other resources like authors (author can have written many books and often enough many authors work together on a single book) or even publishers. Categories too I would assume to be many to many.

When sombody selects a single label from above URIs (/book/{book_id}/labels) you can of course then fall back to your normal label URI (/label/label_id) instead of constructing extra long paths like (/book/{book_id}/label/{label_id}).

So keep your routes as shallow as possible, avoid to nest them too deep. But nothing prohibits to have different views on lists of similar things.

Related Solutions

RESTful reference representations – semantic link vs uri

I would rather have:

{
  "username": "paul",
  "address": {
      "rel": "related",
      "href": "http://example.com/account/paul/addresses"
  },
  "history" {
      "rel": "related",
      "href": "http://example.com/account/paul/history"
  }
}

This eliminates the array and makes the object traversable (to get the address of an account e.g. in JavaScript one could say account.address.href instead of looping through all links and finding one that looks like an address). Corresponding XML:

<account>
    <username>paul</username>
    <addresses>
        <link rel="related" href="http://example.com/account/paul/addresses" />
    </addresses>
    <history>
        <link rel="related" href="http://example.com/account/paul/history" />
    </history>
</account>

What do you think?

REST API Design – Using Email as Identifier in RESTful URI

There are two sub-questions to your question:

Can I use unique but mutable identifiers in my URLs?

This can work well if either the IDs change only infrequently or if the URLs containing those IDs are not used outside your site. As REST APIs usually are built on the premise that any given URL can be re-used to access the same resource at any later time, that second condition goes a bit against the idea of REST.

That leaves the probability of changes to the ID and if you are willing/able to redirect requests made using an old ID. With (encoded) email addresses, this can probably be realized, because an old email address will not be re-used by a different user that often.
Can I use email addresses as my unique ID?

As indicated by the answers of @LucFranken and @9000, using a plain email address in your URL is a bad idea, but you can use an 'encrypted' form of an email address as ID. This 'encryption' can be as simple as base64 encoding.

Best Answer

Related Solutions

RESTful reference representations – semantic link vs uri

REST API Design – Using Email as Identifier in RESTful URI

Related Topic