> > I don't think there is a Resource.storeRepresentation() method in > 1.0.8. Are you recommending this because my approach won't work, or > because .storeRepresentation() is better in some way? >
You are correct, sorry for the confusion. In 1.1, the correct method to override is storeRepresentation(). Hmm, well, one language is C#, which seems to support it in its > HttpWebRequest class. Do you recommend using POST instead for this > reason? Stick with PUT. POST isn't what you really want. I don't know the specifics of C# so I can't help you there. My advice was just a general warning that you shouldn't assume that your clients implementation language will have PUT support. I'd test your target languages to make sure. Will using .storeRepresentation() support storing a > representation through POST as well as PUT? No, that would be acceptRepresentation() (1.1) On Mon, Mar 24, 2008 at 11:18 AM, Ian Clarke <[EMAIL PROTECTED]> wrote: > On Mon, Mar 24, 2008 at 10:07 AM, Kevin Conaway <[EMAIL PROTECTED]> > wrote: > > I believe you should override Resource.storeRepresentation() and > override > > Resource.allowPut() -> true instead of overriding Resource.put() > > I don't think there is a Resource.storeRepresentation() method in > 1.0.8. Are you recommending this because my approach won't work, or > because .storeRepresentation() is better in some way? > > > Two pieces of advice on opening up to third-party clients. First, some > > languages (or their associated libraries) other than Java have poor or > > non-existent support for the HTTP PUT method. Just be aware of this > when > > recommending implementation languages. > > Hmm, well, one language is C#, which seems to support it in its > HttpWebRequest class. Do you recommend using POST instead for this > reason? Will using .storeRepresentation() support storing a > representation through POST as well as PUT? > > > Second, while JSON is slightly easier to work with programmatically, a > lot > > of languages don't have native support for it. Depending on who your > > clients are, they might balk at having to download and install a third > party > > library to access your service. XML might work out better because most > > languages have native support for it. > > I think it will be ok. Of course, I can always support both, and let > them choose when they make the request. > > Many thanks, > > Ian. > > -- > Email: [EMAIL PROTECTED] > Cell: +1 512 422 3588 > Skype: sanity >
