Menu
▾
▴
resteasy-users
|
From: Chris B. <cbr...@re...> - 2010-11-24 15:40:13
|
Hi List, I have many typical entity resources to which a POST will create a new instance and return the resource URL as a Location header. However, I find myself parsing this header in my application clients frequently to strip out the ID of the newly-created entity. While the logic is trivial, I feel like it's silly to do this when I control the server logic as well. I'm thinking about adding and Entity-Id header to store the uniqe ID of whatever entities are created at the various resources. Is there any reason why this is bad practice, RESTfully speaking? I would of course leave the standard Location header(s) there. Thanks, Chris |
|
From: Michael M. <mmu...@re...> - 2010-11-24 15:56:55
|
The url in location header is already unique so why do you need to refer to it by another id. Some rest folk say that urls should be opaque so they would advise against parsing it for meaningful information. Mike > Hi List, > > I have many typical entity resources to which a POST will create a new > instance and return the resource URL as a Location header. However, I > find myself parsing this header in my application clients frequently to > strip out the ID of the newly-created entity. > > While the logic is trivial, I feel like it's silly to do this when I > control the server logic as well. I'm thinking about adding and > Entity-Id header to store the uniqe ID of whatever entities are created > at the various resources. Is there any reason why this is bad practice, > RESTfully speaking? I would of course leave the standard Location > header(s) there. > > Thanks, > > Chris > > ------------------------------------------------------------------------------ > Increase Visibility of Your 3D Game App& Earn a Chance To Win $500! > Tap into the largest installed PC base& get more eyes on your game by > optimizing for Intel(R) Graphics Technology. Get started today with the > Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. > http://p.sf.net/sfu/intelisp-dev2dev > _______________________________________________ > Resteasy-users mailing list > Res...@li... > https://lists.sourceforge.net/lists/listinfo/resteasy-users |
|
From: Chris B. <cbr...@re...> - 2010-11-24 18:18:03
|
Yes, the URL is unique. However, consider this scenario: In the RESTful world (API integration world): api.foo.com/things/1234 That's the RESTful representation of Thing 1234. Cool. Now, in a web app that is "downstream" from there, we have a UI and set of forms and whatnot that create Things. There are many other clients too, but it's the web UI that I'm thinking of in this message. That Web UI has something like this: fooweb.com/web/admin/things/1234 or maybe fooweb.com/web/admin/viewThing.jsf?id=1234 In that case, the whole URI of that Thing is not meaningful. While it does identify the Thing, it does not give me the pure entity ID that's useful in the web app. So I must parse. Or I need to provide that ID somehow, hence my initial proposal. Of course it's possible that I'm thinking about this wrong in which case I'm happy to be educated... -CB On 11/24/2010 10:58 AM, Michael Musgrove wrote: > The url in location header is already unique so why do you need to > refer to it by another id. > > Some rest folk say that urls should be opaque so they would advise > against parsing it for meaningful information. > > Mike > > >> Hi List, >> >> I have many typical entity resources to which a POST will create a new >> instance and return the resource URL as a Location header. However, I >> find myself parsing this header in my application clients frequently to >> strip out the ID of the newly-created entity. >> >> While the logic is trivial, I feel like it's silly to do this when I >> control the server logic as well. I'm thinking about adding and >> Entity-Id header to store the uniqe ID of whatever entities are created >> at the various resources. Is there any reason why this is bad practice, >> RESTfully speaking? I would of course leave the standard Location >> header(s) there. >> >> Thanks, >> >> Chris >> >> ------------------------------------------------------------------------------ >> Increase Visibility of Your 3D Game App& Earn a Chance To Win $500! >> Tap into the largest installed PC base& get more eyes on your game by >> optimizing for Intel(R) Graphics Technology. Get started today with the >> Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. >> http://p.sf.net/sfu/intelisp-dev2dev >> _______________________________________________ >> Resteasy-users mailing list >> Res...@li... >> https://lists.sourceforge.net/lists/listinfo/resteasy-users > > > ------------------------------------------------------------------------------ > Increase Visibility of Your 3D Game App& Earn a Chance To Win $500! > Tap into the largest installed PC base& get more eyes on your game by > optimizing for Intel(R) Graphics Technology. Get started today with the > Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. > http://p.sf.net/sfu/intelisp-dev2dev > _______________________________________________ > Resteasy-users mailing list > Res...@li... > https://lists.sourceforge.net/lists/listinfo/resteasy-users |
|
From: Michael M. <mmu...@re...> - 2010-11-24 18:58:48
|
The problem with request such as fooweb.com/web/admin/viewThing.jsf?id=1234 is that you have to track that 1234 corresponds to the URL. Now if the URL moves to a new location you are stuck whereas if you had used the URL as the identifier then you would know it had moved since you would get back a status code such as 301 (moved) or if it gets deleted then a 410 (gone) status code etc. But you can still use the URL in the above query. You would use: fooweb.com/web/admin/viewThing.jsf?id=<url> where of course you would need to escape the <url> As an aside my 2p worth on the use of custom headers is that it builds a coupling between the client and server - it a piece of private information that is shared by clients that are "in the know". Clients that don't know about the header would incur the overhead of having to parse it. Mike > Yes, the URL is unique. However, consider this scenario: > > In the RESTful world (API integration world): > > api.foo.com/things/1234 > > That's the RESTful representation of Thing 1234. Cool. Now, in a web > app that is "downstream" from there, we have a UI and set of forms and > whatnot that create Things. There are many other clients too, but it's > the web UI that I'm thinking of in this message. That Web UI has > something like this: > > fooweb.com/web/admin/things/1234 > or maybe > fooweb.com/web/admin/viewThing.jsf?id=1234 > > In that case, the whole URI of that Thing is not meaningful. While it > does identify the Thing, it does not give me the pure entity ID that's > useful in the web app. > > So I must parse. Or I need to provide that ID somehow, hence my initial > proposal. Of course it's possible that I'm thinking about this wrong in > which case I'm happy to be educated... > > -CB > > On 11/24/2010 10:58 AM, Michael Musgrove wrote: >> The url in location header is already unique so why do you need to >> refer to it by another id. >> >> Some rest folk say that urls should be opaque so they would advise >> against parsing it for meaningful information. >> >> Mike >> >> >>> Hi List, >>> >>> I have many typical entity resources to which a POST will create a new >>> instance and return the resource URL as a Location header. However, I >>> find myself parsing this header in my application clients frequently to >>> strip out the ID of the newly-created entity. >>> >>> While the logic is trivial, I feel like it's silly to do this when I >>> control the server logic as well. I'm thinking about adding and >>> Entity-Id header to store the uniqe ID of whatever entities are created >>> at the various resources. Is there any reason why this is bad practice, >>> RESTfully speaking? I would of course leave the standard Location >>> header(s) there. >>> >>> Thanks, >>> >>> Chris >>> >>> ------------------------------------------------------------------------------ >>> Increase Visibility of Your 3D Game App& Earn a Chance To Win $500! >>> Tap into the largest installed PC base& get more eyes on your game by >>> optimizing for Intel(R) Graphics Technology. Get started today with the >>> Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. >>> http://p.sf.net/sfu/intelisp-dev2dev >>> _______________________________________________ >>> Resteasy-users mailing list >>> Res...@li... >>> https://lists.sourceforge.net/lists/listinfo/resteasy-users >> >> ------------------------------------------------------------------------------ >> Increase Visibility of Your 3D Game App& Earn a Chance To Win $500! >> Tap into the largest installed PC base& get more eyes on your game by >> optimizing for Intel(R) Graphics Technology. Get started today with the >> Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. >> http://p.sf.net/sfu/intelisp-dev2dev >> _______________________________________________ >> Resteasy-users mailing list >> Res...@li... >> https://lists.sourceforge.net/lists/listinfo/resteasy-users > ------------------------------------------------------------------------------ > Increase Visibility of Your 3D Game App& Earn a Chance To Win $500! > Tap into the largest installed PC base& get more eyes on your game by > optimizing for Intel(R) Graphics Technology. Get started today with the > Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. > http://p.sf.net/sfu/intelisp-dev2dev > _______________________________________________ > Resteasy-users mailing list > Res...@li... > https://lists.sourceforge.net/lists/listinfo/resteasy-users |
Thanks for helping keep SourceForge clean.
X