1

I'm trying to design the data schema and the restful api for a specific case.

In my system I have several users and several books. Every book can have several users as authors and at the same time every user can be an authors of several books.

Now the hard part, users are interested to have a list of their books and to let the system know they are the authors, but it's important that they can also keep this association private. So a user can be the author of a book but doesn't want to make this information public.

Now a first solution can be to replicate the books information for every author and set them as private or public but this is not what I want. My idea was to use two associations in the user entity (books, public_books) where the second one is a subset of the first one.

But another problem comes with the restful api. I'm not sure what is a good way to expose this kind of data.

Something like this maybe?

/users/:id/books

that returns a list of books made with an additional boolean property ispublic?

Is there a better idea to handle this situation in your opinion?

EDIT: The REST API needs to return all the books linked to the user and offer a way to distinguish between public and private books. A user can obviously see all his books, but only the public books of the other users.

Another necessary thing is the possibility for a user to change the status of one of his books. A private book can become public and viceversa.

2

But another problem comes with the restful api. I'm not sure what is a good way to expose this kind of data.

Any way you like. REST doesn't care, so long as the application state is completely captured in the hypermedia. In particular, REST doesn't care how you spell your URI.

Convention is to express hierarchy in the path, and filtering in the query. For your case, that might mean

/users/:id/books?public
/users/:id/books?private

or

/users/:id/books?visibility=public
/users/:id/books?visibility=private

Alternatively, you can think about the context of the data -- what is the application trying to do when it is looking at these book collections. For example, you might decide that there should be a "profiles" resource

/users/:id/profiles/private/books
/users/:id/profiles/public/books

Or even several of these -- there's no rule that there must be no more than one URI that returns a particular data representation. You just need to figure out how many different paths you want to support.

| improve this answer | |
1

Every book can have several users as authors and at the same time every user can be an authors of several books.

So you have an n:m relationship. No problem, that justmeans you'll need a link table that references both entities.

they can also keep this association private

Even less of a problem: you add visibility as another attribute to the linking table.

In which format you expose this information via REST is really a different question, and impossible to decide without knowing your requirements better.

| improve this answer | |
  • I'll try to add further details about the REST requirements to clarify that. Thanks. I add that unfortunately adding a property to the association itself it's not supported on the ORM i'm using at the moment. – heapOverflow Jan 20 '16 at 14:45
  • @heapOverflow: Then it sounds like you'll need two associations, public_books and private_books. Use a UNION ALL query to get all books for one author. – TMN Jan 20 '16 at 15:07
  • @TMN: that was what I designed at first. The fact is that I simplified my case a little bit here, and with all the details I found to be a better fit for my problem to use books and public_books. Do you see any specific problem that I may be missing? – heapOverflow Jan 20 '16 at 15:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.