First of all I want to make it clear that I have nothing against XMLSERVICE. I think it is a nice tool though I never had to work with it due to my current job and thus have no real life experience with it.
And this ranting is not really about the product itself but more about the marketing and what the marketing does to the IBM i community.
So what bugs me most is the marketing of "Now you can offer REST services to the world!" If it would have been marketed not as REST services but as web services there wouldn't be anything to rant about because there is no real/strict definition of what a web service really is (though many people have some strong expectations when they hear about web services).
The W3C defines a web service generally as:
A web service is a software system designed to support interoperable machine-to-machine interaction over a network.
And I want to throw in that I am no REST service expert by any means but even myself with my intermediate REST service skills I see many flaws in the way it is marketed.
First of all REST is all about the resource and the resource is stated in the URL. So if I want some information about a book the URL may look like this:
where 1234 is the id of the book.
With XMLSERVICE you call the global XMLSERVICE program. You don't call the resource you want to know about.
Another thing is that the HTTP method is directly linked to the action you want to execute on the resource. GET retrieves some information and DELETE deletes the information on the server. With XMLSERVICE there is no such mapping to HTTP methods. AFAIK there are only GET and POST supported.
What about the mediatype? Normally you would want to support at least JSON and XML and perhaps even some other format. But the media type does not only state the expected return format of the information. It can contain much more, f. e. the API version.
HTTP Status Codes ... what about the returned status codes. I would expect a 404 if the book is not in the database of the server. What about authentifiation and authorization status codes? Or if the user cannot update the resource because it is blocked by some other transaction? I would want the user to be informed about that. Just throwing some 500 or not even at all (actually I don't know what XMLSERVICE does in these cases) is not good. Fact is that the program which handles the resoure should set the HTTP status code and not XMLSERVICE.
There are probably many other details that are not correct when calling XMLSERVICE a REST service provider. But that is not really the point here. In calling XMLSERVICE a REST provider or a framework/toolkit which can provide REST services (which it obviously doesn't) you make it look non-professional. For someone really deep into REST services this more or less looks like a joke (which it definitely isn't). But developers from other platform are laughing about this:
A: "Hey, you know ... IBM i now can provide their data as REST services. *giggle*"
B: "Yeah ... *giggle* ... at least I can get the data with some HTTP call."
So calling XMLSERVICE a framework for creating REST services is also adding to how other developers (from other platforms) see the IBM i platform (and i don't mean in a positive way).
The only technical argument I have with XMLSERVICE: Actually I don't understand the rational about the design concept of XMLSERVICE. In (almost) every language there is the trend to make small libraries which do exactly one thing and with as little dependencies as possible to build modular applications. But XMLSERVICE is the exact opposite.
If you can't be mainstream stop pretending to be mainstream when you obviously are not.
And again I would like to mention that I find it great to have XMLSERVICE because it adds to the small list of tools and libraries available to IBM developers whereas developers on other platforms can't even count the number of tools/libraries available to them.
End of my rant.