Response based on user

[Emanuele DelBono]

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?

thx

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

[Jim Webber]

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]

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]

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]

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.

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

[Paul Moore]

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]

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]

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.

http://graph.facebook.com/me?access_token=asdf23sf

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)

==> GET http://example.org/authz?user=<id>

<==

{ 

   photos: http://example.org/photos?access_token=23423434123,

   settings: http://example.org/settings?access_token=23423434123,

   …

}

.savas.

--

[Darren Hobbs]

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]

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]

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]

Ah thanks for that... an obvious enough solution.

Dan

[Mitch Trainham]

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.