rest-discuss at Yahoo! Groups

Re: Complex search API

Will Hartung — Mon, 09 Nov 2009 22:24:57 GMT

... I discussed something like this as an answer to a StackOverflow question.

Re: Complex search API

William Martinez Pomares — Mon, 09 Nov 2009 20:31:07 GMT

Hello Sergio. All the above suggestions are great. I will just add the concept view. You see, PUT is for saying: here I have a representation payload for a

Re: Complex search API

mike amundsen — Mon, 09 Nov 2009 18:28:48 GMT

Sergio: The PRG pattern Seb mentions is also a very nice way to support "stored" queries if that is a possible feature. Using POST can result in creating

Re: Complex search API

Sebastien Lambla — Mon, 09 Nov 2009 17:42:33 GMT

I personally use POST plus a typical PRG to achieve the same -> POST /query Content-Type: application/x-www-form-urlencoded Param1=blah&Param2&another+thing <-

Re: Complex search API

Jan Algermissen — Mon, 09 Nov 2009 14:08:37 GMT

... I suggest you take a look at OpenSearch.org. Make sure you look at the parameters extension - that should provide you with the descriotive part of your

Re: Complex search API

Jeff Robertson — Mon, 09 Nov 2009 14:03:33 GMT

How complex? Search engines get a lot of mileage out of query parameters. ... -- Sent from my mobile device

Complex search API

Sergio Bossa — Mon, 09 Nov 2009 13:53:26 GMT

Hi guys, I have to model a REST API supporting complex search operations: that is, I have to submit a kind of query document, and get back a response

Re: Service descriptions and legal contracts

Jan Algermissen — Mon, 09 Nov 2009 12:55:59 GMT

... Picking this up again: Hypermedia specifications[1] implicitly define goals. They do this by establishing semantics on resources[2] and expressing client

Re: Self descriptiveness issues with general media types?

William Martinez Pomares — Sun, 08 Nov 2009 22:20:14 GMT

Hello Jan. Sorry to mix this in. In WSA world, particularly the SOAP definition, you have headers. The idea is that you may want to have intermediaries or

Re: Service descriptions and legal contracts

Andrew Wahbe — Sat, 07 Nov 2009 06:23:02 GMT

... Yes this terminology is something worth getting consensus on. I was using the terms "client" and "underlying platform" for your "user agent" and "client

Re: Service descriptions and legal contracts

Will Hartung — Sat, 07 Nov 2009 00:17:13 GMT

... When talking machine to machine, I don't think a REST client is any different in terms of rigidity than any other remote protocol. The REST client will do

Re: Service descriptions and legal contracts

Jan Algermissen — Fri, 06 Nov 2009 23:26:31 GMT

... Yes, exactly. When a service uses Atom and chooses some kind of extension, the client is unable to know this before the interaction because it cannot be

Re: Service descriptions and legal contracts

Jan Algermissen — Fri, 06 Nov 2009 21:37:13 GMT

... I meant that (ideally and stretching the point) services should make use of as much hypermedia as they can. If they know about foo links and if they can

Re: Service descriptions and legal contracts

mike amundsen — Fri, 06 Nov 2009 21:32:05 GMT

Jan: - services should only use media types understood by all clients - services should use as many hypermedia 'options' as possible (so if a client

Re: Service descriptions and legal contracts

Andrew Wahbe — Fri, 06 Nov 2009 21:27:46 GMT

... Well not quite. I don't think you can expect "all clients" to understand the same media types. I'd say something more like: - services should use the media