Hi John, Agreed on both counts. Still, that is where some interop sessions would come in handy IMO (even though, those are not OAuth specific). As for the 201 response code, that's the approach I'm taking in my code - RESTful all the way (well, trying to)! :)
Hubert On Fri, Apr 3, 2009 at 5:32 PM, John Kemp <[email protected]> wrote: > > Hello Hubert, > > On Apr 3, 2009, at 6:36 AM, Hubert Le Van Gong wrote: > >> >> How many implementations out there support both 200 and 201 >> as valid responses from the Service Provider (when returning the >> access token). >> From a RESTful point of view I'm tempted to use 201 but I'm unsure how >> consumer-side implementations behave. > > I would suggest that this is an HTTP-level question, not specific to > OAuth. And, the OAuth spec. (rightly IMO) defers to HTTP on the > subject of HTTP response codes ([1] section 6.3.2). > > RFC 2616 says about the 2xx class of status codes [2]: > > "This class of status code indicates that the client's request was > successfully received, understood, and accepted. " > > If there are OAuth client libraries out there that implement HTTP > incorrectly, I would suggest they should be fixed, as they also don't > implement the OAuth spec. correctly (HTTP 200-level codes all indicate > success). > > There might be an argument for suggesting that when an access token is > created, an HTTP 201 status would be the _only_ relevant status code, > according to the HTTP spec... (although 202 followed by later 201 > seems possible as well). > > - johnk > > [1] http://oauth.net/core/1.0/ > [2] http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
