Sam Ruby

author
+ Follow
since Jul 23, 2003
Merit badge: grant badges
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Sam Ruby

In HTTP, authentication is done via headers too, the key difference being that these headers are outside of the document itself.

If you are using servlets, the best place to start is by looking up the word "Realm" in how you configure your service (conf/server.xml) in your product's documentation.
16 years ago
It sounds to me like you are trying to GET a document. Why not assign that document a URI, and simply GET it? What additional functionality is Axis providing for you in this scenario?
16 years ago

I don't know if you can publish the URL to a RESTful service to UDDI
(Sam might know). Assuming you can, it's not going to look like other
services in the directory.



The UDDI specification is pretty much description language agnostic, just like the specification of WSDL is schema language agnostic; that being said, Leonard's second sentence comes into play: if you wanted to publish a WSDL that didn't use XSD, don't expect much interoperability. Similarly, if you want to publish your WADL file as a UDDI tModel, don't expect much interoperability.
16 years ago
REST is what you used to POST your comment on javaranch, and what you are using now to GET my response.

In web terms, SOAP is an protocol designed to be invisible to the web, you can't simply copy/paste a SOAP URL into an IM session or into a mashup.

Which is easier to program to depends on what tools you are using. In some environments, producing a WSDL file is a mouse click, and consuming that same WSDL file is another mouse click.

The downside is that such interfaces tend to be brittle, and often end up being inadvertently vendor specific -- due to the wide variety of options that WSDL supports, and the various subsets that each individual vendor choses to implement.

By contrast, coding methods like GET and POST are just about as easy in pretty much every programming language with the right toolkit; but they don't parse the datastream. What we have found is that using tools for parsing html or using XPATH does the job in most cases, and doesn't create inadvertent vendor lockin issues and keeps your code resilient from most data format changes.
16 years ago

do we need to take care of "multiple-accidental-clicks-for-credit-card-purchase-order" kind of problems in the RESTFul web service code itself when we are using POST URL's to expose the service (resource)



Short answer: yes. But the good news is that there are standard patterns for doing this.
16 years ago
inadvertently, eh?

In general, too many URIs is less of a problem than not enough. If you have URIs where POST can mean one of several distinct things, based on the content passed, then the coupling isn't particularly loose. SOAP, as it is typically is used, does this.

URIs constructed based on out-of-band information is also an example of tighter coupling. WSDL, and potentially WADL are examples of this.

I've also seen systems where session state is achieved via a technique called "url rewriting". Sessions are an example of shared state, and tighter coupling.

The problem here is that, in general, one can't take a look at a singe URI, or even a single request and determine if a system conforms to the constraints of REST. If one tries hard enough, one can always produce a tightly coupled system.

More common inadvertent mistakes include using GET for non-readonly requests, and overloading POST, particularly using POST unnecessarily for read-only requests.
16 years ago
First, it is not crucial. You can get by with less. What I have found important, however, is that if you start with a clean design and then optimize and/or make tradeoffs generally works better than if you prematurely optimize for limitations in various tools. The current Ruby on Rails support for REST follows this model: a clean design with alternative interfaces for those who can't do PUT or DELETE.

PUT and DELETE support is wider than you might think. The one place where it is most notably lacking -- HTML Forms -- is also a place where not much WS-* interfaces work.
16 years ago
WS-Transaction, as currently spec'ed, is based on SOAP. There is nothing preventing a similar facility being designed with HTTP headers in mind, but that work hasn't been done yet.

It is also worth noting tht WS-Transaction comes in two flavors: tightly coupled (Atomic) and loosely coupled (Business Activity). Much of the focus in the WS-* world is on the tightly coupled version.
16 years ago
Continuing with a purchase order example, purchase orders often contain fields like dates and decimal numbers. When I was younger and less cynical I found that interoperability was hard, and wrote this.

This lead to my joining a group called SOAP Builders and hosting or co-hosting the first three interop events. This ultimately lead to the formation of WS-I, and my coming to the realization that layering on of greater and greater abstractions doesn't solve these problems; instead what you find is that abstractions leak.
16 years ago

In the sample Chapter 4: The Resource Oriented Architecture) you actually give "a row in a database" (p.81) as an example of a resource. Isn't that level of granularity typically a bit too fine? Wouldn't you usually aggregate your resources to a much coarser granularity?



You often would. A search result may show 10 to 50 rows. A directory listing may show hundreds. Each result would be hypertexted linked to something that is of a finer granularity.

Another example of a resource that really surprised me was "the result of running an algorithm". How is that different from deploying a service at a specific URL?



Services and resources aren't non-overlapping sets. Is google.com a service or a resource?
16 years ago
In the book, we try to use the term "ROA" for Resource Oriented Architecture, which is a subset or profile of REST.

One thing that ROA and SOA have in common, and in start contrast to things like WSDL and CORBA, is that instead of trying to abstract away the network, they recognize that machine boundaries are important architectural facets, e.g., places where trust boundaries often exist.

Where they differ is that SOA focuses on services (verbs), and ROA focuses on resources (noun). A concrete example to illustrate the subtle difference: Google is SOA and ROA. Google is a service (search). You send that service a request, and you get a reply. The same endpoint is also a resource. If you do a GET on Google's home page, you get an concrete representation of a form (in this case, in HTML). That form tells you how to construct requests to other resources (i.e., pages containing search results). Since those pages are resources, they can be bookmarked, linked to from JavaRanch, send over IM to your friends, etc.
16 years ago
Dinesh, if you go to a site on the web that involves purchasing an item using a credit card, you will often see the url change from to . What that means is that the web request is being sent over a secure socket. On top of that you can use your choice of HTTP authentication mechanisms, though with a cryptographically secure socket, many find that basic HTTP authentication is sufficient.

Is that a good reason to migrate? That's not so clear. What I am saying is more along the lines of: given that there are other reasons to switch, use of https can help with your encryption requirements.
16 years ago