Pragmatics

# re: Pragmatics

Mark Nottingham
Posted @ 2/17/2006 9:33 AM
Nice.

I'm with you 100%. The whole point is to tilt some of the decisions so they're easier to make :)

# re: Pragmatics

Ward Harold
Posted @ 2/17/2006 11:40 AM
I can't comment on .NET but, at least with the tools I've used, "great" is not an adjective I would use to describe the experience of accessing a WS, with published WSDL, using Java. My experience using EMF to GET, POST, PUT, DELETE POX in Java has been pretty satisfying.

As always others mileage may vary.

# re: Pragmatics

Dilip
Posted @ 2/17/2006 11:49 AM
Don
For the rest of us who don't exactly float at your level could you elaborate what you mean by "[...] screw with GET at your peril."? Sam Ruby also seems to have latched on to that statement.

# re: Pragmatics

David Totzke
Posted @ 2/17/2006 11:50 AM
>>If you want to reach both audiences before your competition does, you'll avoid indulging in religious debates and ship something.

That's why we love ya Don! Well said.

# re: Pragmatics

Jeff Atwood
Posted @ 2/17/2006 12:55 PM

It doesn't matter. The simpler approach is going to win, like it does every single time.

History tells the story.

# re: Pragmatics

Ishisaka
Posted @ 2/17/2006 3:40 PM
I was going to take it up with my Blog (Japanese).
"you'll avoid indulging in religious debates and ship something."
It agrees.

# re: Pragmatics

RichB
Posted @ 2/18/2006 1:22 AM
I'm surprised you missed the "cool kids" wire format - json.

To add to your list:

Web Services or REST.
Web Services are always SOAP. REST can be SOAP, POX or JSON.

Therefore the decision between WS or REST depends on how much control over the client you have. If you have very little (eg it's a web browser), then you will probably want REST. If you want to go cross-domain from a web browser, then you probably want REST with JSON.

ie You need to look at the big architectural picture. Too many people try to build the academically best API possible - which always results in WS and usually the WS-* specs - which prevent a large number of customers from using the API. It's up to the business as to whether this is a problem or not.

Finally, notice that REST/JSON is simply and XSLT transform away from REST/POX. KISS.

# re: Pragmatics

Al
Posted @ 2/18/2006 2:09 PM
Nice one Don, Hmm I think REST all the way unless your using :

1) .NET
2) J2EE i.e. JBOSS,BEA,WEBsphere etc..

Even Most Java web devs prefer REST, it just the J2EE set that may differ (these have toolsets around SOAP, WS*). In .NET you are actually encouraged not to use REST and of course SOAP, WS* is defacto.

REST is also much better and more scalable when it come to ajax. Yes you can use JSON but makes it difficult to create a natural degradeable experience (backing down to trad html resouces/urls).

Just my experience though could be wrong..
regards
Al

# re: Pragmatics

Oran
Posted @ 2/18/2006 3:14 PM
RichB: Don knows what JSON is. He demo'd a JSON binding for Indigo during the BillG keynote at PDC05.

Hopefully with Indigo we will be able to write a service once and expose it as SOAP, REST/POX, JSON, and more simply by plugging in different bindings. Of course how to build a service that feels natural to non-toolkit users of those bindings will take some guidance...

I'm hoping Clemens can help out here, since it's obvious he "gets it" that Indigo can be anything to anyone and has proven he knows how to make it happen.

There may not be a canonical REST/POX implementation, but you can surely give people the tools to do it how they like. And I'm sure a default implementation would hit the 80% sweet spot, although people might call you evil for not building the "right" default...

Please don't let politics get in the way of letting Indigo be the Swiss army knife that it was designed to be.

# re: Pragmatics

Al
Posted @ 2/18/2006 3:52 PM
Although good REST design is about making obvious and understandable without having to read documentation. Delicious is a great example it just makes sense.

Any tool that converts from say SOAP WS* is not going to convey that simplicity and understanding that design brings.

I'm not nocking Indigo here by teh way, just commenting on why REST may be good in the first place.

regards
Al

PS Don these Captchas can be hard for even me to read sometimes ;)

# REST for work - WS for ??

frogman
Posted @ 2/18/2006 7:55 PM
REST was working when the first W3C working group was formed. Years later we have a hodgepodge stack of W3C WS- specs that make no particular sense and have no history of practical use. Which should I use:
- Something tested and proven on the WWW for more than 10 years, or
- Something created by (many) different committees and that hasn't been tested?

# re: Pragmatics

Philippe Mougin
Posted @ 2/19/2006 6:38 AM
I'm quite surprised by Don Box's comment about SOAP/WSDL providing a great experience to Java folks. JAX-RPC (the standard Java API for using SOAP and WSDL) is known to be a terrible API (see http://rmh.blogs.com/weblog/2005/06/jaxrpc_is_bad_b.html) and certainly not something providing a great experience (except in marketing material).

# re: Pragmatics

Kit Davies
Posted @ 2/20/2006 1:02 AM
I think your IT security strategy needs to be factored into the design decision too. The organisation I work for, like many others, lock down their web servers so only GET and POST are allowed. REST has to be emulated using method parameters.

Otherwise REST would be my first choice on the basis of simplicity.

# re: Pragmatics

Jeremy Ferry
Posted @ 2/20/2006 7:59 AM
I've been looking into the REST vs SOAP thing lately for a project I'm working on and I've been seeing a common thread through all the debates - people think that simply talking in XML is what REST is about.

Now I'm no expert on any of this but my understanding of a RESTful application is that it's more than just providing logical URLs and producing/consuming XML. It's about exposing your application as a big state machine through a standard network protocol - HTTP.

The URLs provide a resource centric view of your domain. The XML part is just a common denominator for communication. The key to REST is in the stateless nature of the system and how standard HTTP can be used to query and modify the state of the system.

It seems to me that a big part of REST is the end goal of exposing an application as a state machine not just a service end point.

# re: Pragmatics

Al
Posted @ 2/21/2006 12:03 PM
I would agree with Kit, most of the REST stuff we do is not actively built assuming PUT and DELETE are available (due to http filtering at coporate edges, as well as proxy complications).

PUT gets mapped onto POST by context (Posting to something that doesn't exist (~Creating) is different from Posting to something that does exist (~Updating). Deleting can be considered a terminal form of updating ;)

One also has to be very carefull about stateless destruction (making it to easy to delete) for security reasons.

PS. Why do I also get the real difficlut Captchas, where the lines bissect near the centre?

# re: Pragmatics

pwb
Posted @ 2/21/2006 12:34 PM
I think Dare summarized my feelings on the subject:

- SOAP/WSDL is OK/good for an audience of several dozen/hundred, mostly .net and Java users.

- REST/POX is OK/good for an audience of thousands/millions of users on a variety of environments.

Here's my issue with REST/POX: no one is describing how such an interface should really be constructed. REST/POX is much, much too conceptual even after it's been around and suppsoedly used for many years now.

ps agree that your captchas are extremely hard to read.

# re: Pragmatics

Keith J. Farmer
Posted @ 2/21/2006 8:05 PM
As much as I curl up in a fetal position when faced with Java Madness (tm), one of the high points was the actual ease with which I could get Java talking SOAP. Of course, I had to use the standard Apache AXIS library (nice how Java has all these conflicting standard libraries available to it). It was also (relatively speaking) painless to get Perl talking to the SOAP service in .NET.

Really, it's all about toolkits, and IMHO they are fools that deny them.

Indigo, at least, should hide the choice of toolkit, and prompt people to follow suit. Then we can ignore the religious debate and just plug in another transport.

# REST vs SOAP

Michael Teper
Posted @ 2/27/2006 2:42 PM

# XINS is a great experience, too

Ernst de Haan
Posted @ 2/27/2006 11:57 AM
If you want a great experience for Java development, use XINS. It offers an extremely simple protocol (REST-RPC) and a very simple specification format (unlike WSDL) and generates client-side code, server-side code, specification docs, testforms, OpenDocument files, WSDL, etc.

At run-time, a XINS applications supports REST-RPC, XML-RPC and SOAP. It automatically detects which one is applicable and it can be extended to support more protocols.

That's what I call a great experience :-)

# re: XINS is a great experience, too

Ernst de Haan
Posted @ 2/27/2006 11:59 AM
Sorry, I forgot to post a link to XINS:
http://xins.sourceforge.net/

FAQ:
http://xins.sourceforge.net/faq.html

XINS Primer tutorial:
http://xins.sourceforge.net/primer.html

Wikipedia page on XINS:
http://en.wikipedia.org/wiki/XINS

# re: Pragmatics

Jeffrey McManus
Posted @ 2/28/2006 11:03 AM
I don't know who believes that "Web Services are always SOAP" anymore. This was a minority opinion for about 15 minutes back in 1999 but it's definitely not true today.

# SOAP vs. REST

jkeyes.com
Posted @ 3/2/2006 1:50 PM
Great little summary of the old SOAP vs. REST question, from Don Box. Decide which to support based on your target audience. When I develop in PHP, I prefer REST, but when I'm in Microsoft's Visual C# environment, SOAP is...

# The Russian Doll Approach to Web Services

Dan McKinley
Posted @ 3/6/2006 4:26 PM
Here's an anecdote for the WTF inbox. I assure you this is very real, but I cannot divulge any of the...

# re: Pragmatics

Erick
Posted @ 3/15/2006 9:44 AM
The simplier the better. That's unspoken rule of any start.

# re: Pragmatics

helen, wen designer
Posted @ 5/17/2006 11:26 PM
Just read a great article on rest. Just some extracts from it:
"REST is a term coined by Roy Fielding in his Ph.D. dissertation [1] to describe an architecture style of networked systems....The key to creating Web Services in a REST network (i.e., the Web) is to identify all of the conceptual entities that you wish to expose as services."

# re: Pragmatics

yan
Posted @ 5/25/2006 2:35 AM
Can you Email me please ,I really need you to do me a favor.
Thanks a lot!

My email :

ytguo3062002@yahoo.com.cn

# re: Pragmatics

Joddie
Posted @ 5/30/2006 12:36 PM
It doesn't matter. The simpler approach is going to win, like it does every single time.

# re: Pragmatics

Joddie
Posted @ 5/30/2006 12:43 PM
It doesn't matter. The simpler approach is going to win, like it does every single time.

# re: Pragmatics

Josey
Posted @ 6/5/2006 1:56 PM
Just read a great article on rest. Just some extracts from it:
"REST is a term coined by Roy Fielding in his Ph.D. dissertation [1] to describe an architecture style of networked systems....The key to creating Web Services in a REST network (i.e., the Web) is to identify all of the conceptual entities that you wish to expose as services."

# re: Pragmatics

Candy
Posted @ 6/5/2006 1:57 PM
yes, true things! right!

# re: Pragmatics

jamesguan
Posted @ 7/4/2006 11:22 PM
So good that I have ever heard the exposition about pragmatics in social usage!

# Let's REST!

Alex Barnett blog
Posted @ 7/21/2006 6:22 PM
A bunch of links to RESTful resources I've collated here and there - should be a good starting point...

# Pragmatics

admlas
Posted @ 10/2/2006 12:33 PM
What is this???!! no one is going to read this!! I sleep with tihs, where are the examples?? the things that explain all??

EXAMPLES!!

# re: Pragmatics

admlas
Posted @ 10/2/2006 12:36 PM
THIS IS VERY STUPID!!, THIS PAGE IS VERY STUPID THERE IS NOT SO MUCH INFORMATION AS I WAS THINKING THIS IS A STUPID PAGE!!! FUCK YOU!!!!

# Opinion wanted

Patents
Posted @ 10/29/2006 7:14 AM
Hi,

Great thread. Given that you all seem to have a lot of knowledge about these topics, I'm wondering if I oculd present a hypothetical situation to you and get your opinion on the best way to proceed.

We run a searchable patents database which currently has an XML feed using regular get/post. We are thinking about making this more sophisticated (but honestly, there isn't anything identitified right now that users need to do that they cannot do with the current interface -- so I guess one question is whether I am "fixing" a problem that doens't exist, but I am also trying to "future-proof" the service).

Internally, we are LAMP. We'd like to encourage users to develop in Java since we can help support that, and portability is a desired trait (I'm considering opening portions of our servers up to the community at large and starting an open source initiative for patent tools). Nothing against .NET, but we don't do it in-house, can't support it, and I think it would impair an open-source initiative (am I going to get flamed for that?).

Given this situation, what protocol do you suggest? If you would like to contact me directly, my email is jryley at freepatentsonline dot com.

Thanks,
James

# re: Pragmatics

Hao
Posted @ 2/15/2007 1:20 PM
hi, James,

I would highly recommend the REST approach. Your application is fundamentally resource-oriented so the REST approach is the best here.

# re: Pragmatics

Zesty RESTy
Posted @ 4/11/2008 2:01 PM
So after a decade of work and thousands of person-hours from super-duper-brains at Sun, Microsoft, IBM etc., do the Java and .NET programmers in the SOAP/WSDL world have a much easier time integrating software systems than the LAMP people do? That was the point, right?