"It was mostly the work of a coworker, Dylan Wolf, as he created the UPS module. I came back later and added the FedEx portion. FedEx's setup was so ridiculously hard to get working I thought surely someone else out there had done the same thing, but alas, no. So I'm glad someone wanted it, specifically because of the effort involved.
"The way you interact with FedEx is particularly ridiculous. For example: You can't give FedEx a list of boxes and get back a list of prices (as you can with UPS). Each box has to be a completely new transaction. UPS would understand "I want to mail 4 boxes weighing 10 pounds and two weighing 2 pounds to zip code 12345 from zip code 54321." In order to simulate this functionality loop through a given list, making the individual FedEx requests and returning a corresponding list."
---
Clearly, Fedex does not fit the formal definition of "Web Services." But again, everyone who writes about it uses Fedex in their list of examples, so it makes me wonder how much research those people have done, and based on that, how much can I trust the rest of what they've written?
On a separate note, yes, I do think that, if they are so great, then Web Services ought to be easy to use. The argument that the only serious consumers are big companies who have staff programmers to dedicate to the problem is ridiculous in the age of the web. To me, a Web Service should be easy for anyone to access, because everyone should be able to sell things on the Web, and the most common processes are going to be payment transactions and calculating shipping costs.
I seem to remember when Web Services first showed up, they were described as "you just go here to look up the service, then you call it there." Seems like there ought to be modules out there that do all that work for you and make it simple to use -- maybe someone has already written something, but no one has mentioned it here yet.
And finally, what does it mean when two rather important players -- Paypal and Fedex -- do not provide standardized Web Services, but instead have created their own way to do it?
Update: with a few hours of study and a little help, I was able to get Gabriel Cooper's code at: http://opensource.pseudocode.net/files/shipping.tgz To produce results from the Fedex site. As long as you have a Fedex shipping account, you don't need to download anything else from the site. There are a couple of tweaks I needed to make to the test.py file (with Gabriel's help) to get it to work; I'm sending him that file but if you need it before it's updated, let me know and I'll send it to you.
Interesting thoughts. But I'm left wondering if web services is the issue here. It looks to me like the real problem is Fedex's poor engineering (examples, documentation, unintuitive interfaces, poor architecture etc) of customer visible services and APIs.
i.e. It's not a technical issue per se, it's an engineering/quality issue?
I think the point is, hype is the winner here. The web service concept in practice is fragmented and less than ideal, and that's that. However, to hear about it, web services are the answer to everything.
I prefer to think of them as wheels. They've certainly answered a lot, but everyone makes their own brand, so it's not like different types of wheels should or will suddenly merge to be one unified model to fit all needs.
Today I figured out how to use the USPS rate calculation system. After studying both Fedex and USPS, I don't think either of them qualify as "Web Services," but rather something one could call "RESTful XML". In both cases, you formulate a query as XML and send it to a server, which then sends you a response in XML.
It also seems to me that in both cases, regular REST could have been used, and things would have been a lot simpler. That is, the use of XML seems superfluous in these cases. I'm sure that's the first time this has ever happened :-)
> Today I figured out how to use the USPS rate calculation > system. After studying both Fedex and USPS, I don't think > either of them qualify as "Web Services," but rather > something one could call "RESTful XML". In both cases, you > formulate a query as XML and send it to a server, which > then sends you a response in XML.
I think the term you're looking for is XML-RPC, perhaps? It's a simpler idea than SOAP and WSDL and such. Less functionality than those, but on the other hand, isn't that all the functionality you needed?
XML-RPC is different; it's a remote procedure call where the arguments and return values are encoded in XML (to eliminate cross-platform data format differences). A RESTful call uses http.
> XML-RPC is different; it's a remote procedure call where > the arguments and return values are encoded in XML (to > eliminate cross-platform data format differences). A > RESTful call uses http.
Actually, XMLRPC also uses http as the transport mechanism. It's kind of a minimalist SOAP.
True about http. However, XML-RPC has a well-defined method-call mechanism which specifies all the XML tags to make the call: methodCall, methodName, params, param, value, and a set of data types. The method argument parameters are positional, not named, whereas both UPS and Fedex use named parameters and their own protocol which is not XML-RPC; this is unfortunate, because if they used XML-RPC communication would be greatly simplified (Python has a built-in XML-RPC library, for example).
> True about http. However, XML-RPC has a well-defined > method-call mechanism which specifies all the XML tags to > make the call: methodCall, methodName, params, param, > value, and a set of data types. The method argument > parameters are positional, not named, whereas both UPS and > Fedex use named parameters and their own protocol which is > not XML-RPC; this is unfortunate, because if they used > XML-RPC communication would be greatly simplified (Python > has a built-in XML-RPC library, for example).
Yeah, I figured that out. When I posted the first comment I thought it was a bit more of a generic term and not a specific well-defined mechanism. So, not the appropriate term here.
> Clearly, Fedex does not fit the formal definition of "Web > Services." But again, everyone who writes about it uses > Fedex in their list of examples, so it makes me wonder how > much research those people have done, and based on that, > how much can I trust the rest of what they've written?
Is this a reliable litmus test for Web Services books and articles-if they mention Fedex as an example, they lose points?
My complaint is not so much about web services as it is about Fedex.
I am happy with any solution that lets me post data to fedex web site and receive back the shipping label in PDF format.
There appears to be no simple way of doing so. I would imagine someone would have written a program in Java or C that just needed a Meter number, had an interface that looked just Like Fedex Label, and allowed you to create a label and print it.
Alas! No such luck.
I talked to a lot of people at FedEx - they are really very friendly, and refer to third party vendors who make sales pitch to do the thing for you.
If anyone can post simple pointers, I will be very grateful.
Flat View: This topic has 26 replies
on 2 pages
[
«
|
12
]
Previous Topic
