It’s just data

Indigo supporting REST?

Don Box: the HTTP message transport in Indigo Beta 1 gets in your way, as it is hard wired to POST.  We’re fixing this, so you can make up HTTP methods until the cows come home

I left this as a comment on Dare’s weblog, but I thought I would surface it here:

How about fully supporting GET?  Things like content type, charsets, permanent redirects, ETags, Last-Modified, gzip or zlib compression, content negotiation, yadda, yadda, yadda...


I’d love nothing more than to see the list of 10 (or 5 or 20) things we need to do to make this feature rock.

Feel free to email them to me or Doug and/or post them here.

DB

Posted by Don Box at

Quite frankly, it is hard.  Let’s start with this rant.

HTTP defines an extensible set of headers.  Some of which can be handled directly by the framework (like compression).  Others of which cause some damage and some good if handled by the framework (like redirects).  Still others require some interaction with the application in order to work properly (like etags).

Just solving those three things (oh, and setting the content type so that you can send images and PDFs to browsers without having to rely on dodgy and vulnerable sniff tests that some browsers *cough* have been known to implement) addresses 80% of the needs, and sets precedents that you can use for determining how to handle other headers and status codes.

I said it was hard.  With all the languages, and all of the libraries that I am familiar with, I don’t know of a single one that I would say does this right.  Python’s, for example, frankly sucks.

What’s odd about this is that the protocol itself isn’t very hard.  In most cases, directly writing to sockets isn’t all that more complicated than using the libraries that where explicitly designed to shield you from all this.

Posted by Sam Ruby at

What’s odd about this is that the protocol itself isn’t very hard.  In most cases, directly writing to sockets isn’t all that more complicated than using the libraries that where explicitly designed to shield you from all this.

The syntax, maybe.  But there has been all sorts of discussion on the correct use of the protocol.  Do the frameworks help address any of the correctness issues?

Posted by anonymous at

Not sure what a stateless framework could do about this, but...

$ grep “ 410 ” ~/logs/diveintomark.org/20050714.log | wc -l
12473

Per day.

Posted by Mark at

After fighting with WSE 3.0 CTP for XOP/MTOM interop, am shuddering to think what hoops we’d have to run thru to get the REST interop with Indigo.

Details : [link] and [link]

— dims

Posted by Davanum Srinivas at

Davanum,

The target customer for WSE is the early-adopter/WS-enthusiast. The engineering focus of WSE has always been “make the protocols work.”

The target customer for Indigo is every programmer on the planet. The engineering focus of Indigo has been “make the programmer more productive with messaging.”

In terms of how simple “REST interop” will or will not be, it’s important to note that a lot of POX and REST services eschew machine-processable descriptions. To that end, I doubt that anyone could duplicate the “Add Web Reference” experience without having the right metadata.

That stated, if one of the 14 description languages got traction (see Dion Hinchcliffe’s blog ([link])  for a survey/shootout), someone could write the metadata importer pretty easily.  I’d be shocked if one emerged in time for us to bake it into V1 however.

DB

Posted by Don Box at

Sam Ruby: Indigo supporting REST?

[link]...

Excerpt from del.icio.us/tag/rest at

Sam Ruby's skepticism of Indigo

Sam Ruby: "The fact that I was able to do all this with but a single line of code — and using only the protocols and products that were already installed — was of great value to me yesterday. In......

Excerpt from Randy Holloway Unfiltered at

Add your comment