2

I'm writing a REST API and i want some feedback. I will have one resource called Items. I want it to be accessed publically or it can be privated (only the user can see it). My First idea was to put a URL to public items like /Root/Items where the public items will live, and other URL like /Root/User/Items where private items will live. An Item can be linked to another user so it will have permission to update it. Something like /Root/User/Operator/Items .... but then i realize i'm creating too many addresses.

I dont like the idea to put all the items inside de /Root/Items url because each user will have a different output. And putting it only inside the /Root/user/Items will be not possible to list all the public items (that can belongs to any user).

Any idea how can i design that?

Lxu
  • 437
  • 1
  • 5
  • 12
  • you need a controller, mod_rewrite and authentication – Teson Jan 12 '12 at 21:30
  • user247245 did not understand the question. – Evert Jan 12 '12 at 21:32
  • 1
    What's wrong with having the returned content of `/items` vary depending on which user accesses it? That's the beauty of dynamic content. The user will only see links to items they have the permission to view. That is a classic concept. – tuespetre Sep 16 '12 at 04:29
  • The following is very similar question. See my answer there: http://stackoverflow.com/questions/35070866/restful-api-best-practices-for-admin-and-normal-user-access/39533131#39533131 – pcjuzer Sep 26 '16 at 07:12

1 Answers1

0

In RESTful architectures every "thing" should have one identifier which is a URI if you use HTTP as I expect. In your case, every item should have exactly one URI.

My First idea was to put a URL to public items like /Root/Items where the public items will live, and other URL like /Root/User/Items where private items will live.

I assume that you are not only talking about collection resources which will return a collection of items. I assume that you will have also single item resources. A URI of a single item could be /Root/Items/42 or /Root/User/Items/23 in your scheme.

You can use different URI schemes for public and private items if it helps you doing the authorization needed. But anyway URIs did not matter in REST. URIs should be always regarded opaque. If you use that different schemes for public and private items, you have to ensure that a public item can never become private and the other way around. If so the URI of a item would change and that's the same as if you would change the primary key of a row in a database. Identifiers should not change. What you are doing if you are using different URI schemes for public and private items is encoding the privacy level of your items into there identifiers. If your problem domain allows this, it is ok.

An Item can be linked to another user so it will have permission to update it. Something like /Root/User/Operator/Items .... but then i realize i'm creating too many addresses.

This sounds like as you want to change the privacy level of an item. As I said before, one item should have exactly one URI which never changes. If you are talking about collection resources, your scheme might be. I'm not sure what you mean here.

At the end: What you need is Authentication and Authorization. You need to return a 403 Forbidden if a user wants to access a private item of another user regardless of its URI.

Alexander Kiel
  • 605
  • 6
  • 9