Response based on user

49 views
Skip to first unread message

Emanuele DelBono

unread,
Feb 8, 2013, 2:18:20 AM2/8/13
to restinp...@googlegroups.com
Hi all

I'm building a REST Api in which a resource could have different representation based on who is calling the API.
For example the Employee resource have 3 properties: Name, Address and Salary.
If the API is called by an Administrator all the properties should be serialized, but if it is called by a User the Salary should not be exposed (since it is a private information).

What to to in these cases? Two different endpoint or a single endpoint with 2 different representations?

Jim Webber

unread,
Feb 8, 2013, 6:27:02 AM2/8/13
to restinp...@googlegroups.com
Hi Ema,
I'd try to make it explicit. If you can't force a separation by URI directly, then why not use a redirect?

So while I'd prefer:

/resource1/user1
/resource1/user2
...

If users are only expected to know the /resource1 resource, then:

VERB (+ credentials for user X) /resource
303 -> /resource/userX

Jim


Emanuele DelBono

unread,
Feb 10, 2013, 1:45:42 AM2/10/13
to restinp...@googlegroups.com
Ok.Thanks for the answer.
That means having two different uris for the resource or it's considered a parameterized uri?

bye



Jim


--
You received this message because you are subscribed to the Google Groups "restinpractice" group.
To unsubscribe from this group and stop receiving emails from it, send an email to restinpractic...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.





--
ema
http://blog.codiceplastico.com/ema

Jim Webber

unread,
Feb 10, 2013, 4:30:41 AM2/10/13
to restinp...@googlegroups.com
Hi,

> That means having two different uris for the resource or it's considered a parameterized uri?

A parameterised URI is just a URI.

The new RFC for URIs makes this clear (whereas the old one said that parameters in URIs provide context for the resource identified by the remainder of the URI).

Jim

Emanuele DelBono

unread,
Feb 10, 2013, 4:51:16 AM2/10/13
to restinp...@googlegroups.com
Yes, make sense. :-)
bye and thank you.



Jim

--
You received this message because you are subscribed to the Google Groups "restinpractice" group.
To unsubscribe from this group and stop receiving emails from it, send an email to restinpractic...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


Paul Moore

unread,
Feb 10, 2013, 8:53:51 AM2/10/13
to restinp...@googlegroups.com
Hi Emanuele,

I also struggled with this.

My eureka moment was when I was looking into Basic Authentication in RFC2617 and further into the treatment of requests with 'Authorization' headers in RFC2616 (see http://tools.ietf.org/html/rfc2616#section-14.8).

The short version is that shared caches must not respond with cached representations to requests with Authorization headers.  This means that authorized requests are not (normally) cached in shared caches. They may, of course, be cached in private (local) caches.

Using the authorization header (e.g. Basic Auth), you can vary the returned representation by user without having to include 'user_id=' or similar in the URI.  The user specificity is already in the authorization header, so it doesn't need to be repeated in the URI.

Thus, I would use a single endpoint (it is the same resource after all) and merely vary the representation by the user.  In this way you can have different representations per user, and even a public resource (without the Authorization header) at the same URI.

Implementation note: My frameworks internal caching arrangement assumed one representation per URI, so I created a filter to translate the request into a parameterised URI.  So, whilst the external URI is /employee/45, the (framework) internal URI is something like /employee/45?user_id=346.  The point here is that the external URI is your public contract, and one that worth some investment to make simple, your internal URI can be anything you like to make things easy for your framework.

Hope that helps

Paul

Dan Haywood

unread,
Feb 10, 2013, 9:17:45 AM2/10/13
to restinp...@googlegroups.com

Reading this thread from the sidelines with interest... thanks for this great info, Paul.

Dan

Sorry to be brief, sent from my phone

--

Savas Parastatidis

unread,
Feb 10, 2013, 3:43:00 PM2/10/13
to restinp...@googlegroups.com
Take Facebook's Graph API as an example (or any Oauth-enabled site). They use an approach very similar to what Jim described without the need to utilize headers.


Based on the access token used*, the correct information is returned.

"me" is mapped, of course, to the actual resource, something like http://graph.facebook.com/savas?access_token=asdfas23ra but I, as a consumer of the API, don't really need to know. The service will read the entire URI and determine what representation to return.

Even in the case of a specific resource, the representation returned is based on the permissions that have been attached to the access-token.

http://graph.facebook.com/savas?fields=email&access_token=2341sadf234sdf will only return the email if the given access token allows it.

I recently had to implement a similar approach for a service, and I followed a similar pattern:

// Entry point to the service (assuming that the user has authorized the service with Facebook, which is a different flow)
<==
   …
}

.savas.


--

Darren Hobbs

unread,
Feb 12, 2013, 7:02:38 AM2/12/13
to restinp...@googlegroups.com
URIs should be completely opaque to clients, in the same way humans
don't need to know how a link in a website is constructed in order to
click on it. Any links that the client needs to follow should be
returned as part of a previous response.

We're currently ripping out all knowledge of how our URLs are
constructed from the clients. They know what key to use to get a URL
(equivalent to the text enclosed in an HTTP anchor tag that tells a
human what's behind it) and that's it. Makes for really robust and
extensible APIs.

Dan Haywood

unread,
Feb 12, 2013, 7:06:59 AM2/12/13
to restinp...@googlegroups.com
On 12 February 2013 12:02, Darren Hobbs <darren...@gmail.com> wrote:

We're currently ripping out all knowledge of how our URLs are
constructed from the clients. They know what key to use to get a URL
(equivalent to the text enclosed in an HTTP anchor tag that tells a
human what's behind it) and that's it. Makes for really robust and
extensible APIs.

You mean the "rel" of the link?
 
Also, I wonder if anybody knows if there is some sort of namespacing of "rel"s, as there is for media types with the "vnd." prefix?

Gael vander Schelden

unread,
Feb 12, 2013, 7:12:20 AM2/12/13
to restinp...@googlegroups.com
In rfc5988 Web Linking you will find that they make a distinction between well known rel that would be defined at IANA (http://www.iana.org/assignments/link-relations/link-relations.xml) and extension that should use an URI this URI can point to a definition or documentation


--
You received this message because you are subscribed to the Google Groups "restinpractice" group.
To unsubscribe from this group and stop receiving emails from it, send an email to restinpractic...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 



--
/* Gaël vander Schelden
GSM: (LU) +352 621 200 155
LinkedIn profile: http://www.linkedin.com/pub/0/365/62a
"Ut ameris, amabilis esto" -- "Use cases are fairy tales..." I. S. 2005 */

Dan Haywood

unread,
Feb 12, 2013, 7:20:06 AM2/12/13
to restinp...@googlegroups.com
Ah thanks for that... an obvious enough solution.
Dan

Mitch Trainham

unread,
Apr 8, 2020, 6:01:12 PM4/8/20
to restinpractice
This seems like a bad approach to use in a general sense, because client applications need to know the structure to expect when calling a URI. If we vary the structure returned by a single URI behind the scenes with the clients being completely unaware of this, it complicates consuming that URI from the client's standpoint. A single URI might return multiple representations based on the format of serialization (JSON, XML, etc), but the client can decide which of the server's format to consume. As a client calling a single UI, I would expect the data to change as state changes, but definitely not expect to get different structures back, especially when I'm unaware of what determines which structure comes back.
To unsubscribe from this group and stop receiving emails from it, send an email to restinp...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages