I code a generic OSLC client, and I want to display to my user, for any OSLC service , its acceptable input parameters (both name and type).
Assuming that I have the URI/URL of all the service providers, the URI/URL of all the services, and the URI/URL of all the queryCapabilities, what path in the graph should I follow to go to the formal description of the inputParameters of a service?
I expected service>queryCapability>resourceShape>property>inputParameters>valueShape to be a good candidate. But, in real life, the inputParameters has only a valueType property (pointing a "LocalResource" which is hardly a precise description of the inputParameters).
Is there a standard path, to figure out the signature of a OSLC service?
Related
I just read a great article on web services by Patrick Cooney at AListApart. However, something is still vague to me on why web service recommendation is important and how it works? Is this approach an alternative for UDDI and similar solutions?
UDDI provides the infrastructure for web service discovery. As the linked article from the comment says, it is basically the "yellow pages" for web services.
If I understand your reference to "web service recommendation" correctly, you mean a system that, given a list of equivalent candidate services, chooses the best one for you, probably based on matching a set of requirements against some kind of QoS metrics of these services.
Therefore, such a system can be used as either an addition to UDDI (if the consumer performs the basic discovery and only delegates the dynamic selection to the recommendation system) or replace it transparently for the consumer (the consumer asks the recommendation system for a service type with some given QoS parameters). In the second case, the recommendation system would use UDDI for discovery and then filter the answer for the consumer based on the QoS parameters.
Is there an MWS or AWS API call that I can make using a product ASIN that will tell me whether or not the information being returned from the Amazon servers is coming from the main product listing or from one of the "additional sellers" that are piggybacking off of the main product listing?
What I'm trying to do is programmatically determine if the MerchantId I'm using in the GetMatchingProductForId() call is the same MerchantId that originally created the product listing on Amazon. If they aren't the same it means (in theory, anyway) that I can work with a much smaller subset of the data, and post just the information that's required for the "Condition" and "Condition Note" values in a Marketplace Offering.
And yes, this question is directly related to How to get Seller Name from Amazon in ItemSearch using amazon API, but the API call and parameters in the answer have been deprecated by Amazon. Literally, the request returns <MerchantId>Deprecated</MerchantId> in the response, so I can't compare the Merchant ID value that I'm using to make the call against the <MerchantId> node returned in the response.
After a lot of (very tedious) research and experimentation I've settled on a series of three MWS API calls to determine whether a product is an Amazon Marketplace Listing or an Amazon Marketplace Offering.
GetCompetitivePricingForSKU -- This call returns an XML CompetitivePrice node containing a belongsToRequester attribute set to "true" or "false". The caveat (and the reason why I'm using three different MWS API calls) is this call fails miserably for merchants that have predetermined shipping charges for their products.
GetMyPriceForSKU -- This call will return an error if the merchant doesn't "own" the Marketplace Listing. Purely anecdotal and empirical, though.
GetMyPriceForASIN -- The least reliable call of these three. Sometimes it will return an XML MerchantSKU node... and sometimes it won't.
Since Amazon doesn't provide any definitive answer (or documentation) for this issue, please take all of this advice with a large grain of salt. Run your own use-cases and see which one(s) work for you.
The GetProductForID is intended to give you details about a product. Mainly this is used to get the ASIN by using a UPC code, and other product details such as bullets, image, size, etc.
If you are trying to see if your offer for the same product is competitive you can either use the GetLowestOfferListingForASIN (to get the asin use the GetProductForID (if you have some sort of id like UPC) or ListMatchingProducts to do a text search). That way you will know what type of offer you need to place to try and get the buy box.
If you are looking to get more details to all the unique offers listed for a product (new, used, etc), then you need to use the subscriptions API (its pretty new). This can get pretty complicated.
When I add a service reference in WCF Test Client all of the exposed service functions are listed but in no order I could figure out...
Is there a way to sort the exposed service functions alphabetically?
Weather in WCF Test Client or in the service itself?
It appears to not be possible.
According to this answer, WCFTestClient will take the same order as the Type.GetMethods method which follows no particular order.
But as pointed out in this other answer, you can just type the first letters of the name of the method to highlight it (I agree this is not what we really want!)
I am developing a SOAP interface and am having trouble deciding what to name the endpoint address.
Options:
- {soap,api,service,???}.foo.com.au
- www.foo.com.au/{soap,api,service,???}
What are the typical names that a SOAP service gets?
I would use www.foo.com.au/soap, mostly because it's an easy way to tell people that it's a SOAP service, and if you want to add a REST service later, you can use www.foo.com.au/rest
Keep in mind, in practice, all solutions are technically equivalent. The benefits of one naming system over another are only at the ease or understanding what the URLs are about (for humans), or maintainability, really. So, if you are searching for a standard we can tell, at best:
If you have a big company with lots of applications, go for the http://api.company.com/application/rest and/or http://api.company.com/application/soap approach
Reason: you can separate, right from the start (networkwise) the web service servers (http://api.srv.com/app) from the human web browsing servers (http://www.srv.com/app).
All applications have one big root "meeting" point (the root URL api.company.com), so if anyone wonders what is company-wide available, just check http://api.company.com and it can list all services available.
If your setup is not that big, it is probably not worth the trouble, so don't fear using the www.. But keep in mind it's best to use at least a different context, such as api/, so that anyone knows right off the bat a service URL is about a web service(!): http://www.company.com/application/api/rest / http://www.company.com/application/api/soap
Note: It's also common to use service, although api seems to be somewhat better descriptive (api.something.com leaves no doubt about what that page is about).
Some examples (as you can see, there is really no global standard):
Google's search API: http://ajax.googleapis.com/ajax/services/search/web?v=1.0&q=test
Twitter's search API: http://search.twitter.com/search.json?q=w00t
Facebook' Graph API: http://graph.facebook.com
Facebook' Dialog API: http://www.facebook.com/dialog (see, no standard even within facebook!)
Weather Gov SOAP forecast: http://www.weather.gov/forecasts/xml/DWMLgen/wsdl/ndfdXML.wsdl
Buy many seem to keep the good ol' company-wide APIs "meeting points":
http://developers.google.com
http://developers.facebook.com
http://dev.twitter.com
I am trying to set up a (for now) really simple web service. By simple, I mean it only has a small amount of actual work to do on the code-side. It only really has one method/function: the client sends a user login, and the service responds with an otherwise very secure detail about the user (for the purposes of this question, let's say the user's birthday).
I have a lot of questions, but for now I'm wondering:
I am considering having two versions of this method. In version one, the client can only make a generic request with no variable information. The service will respond with birthday of whoever is authenticated in the client's session. In version two, the client is allowed to query any user name (so really, anything they want) and get back either the birthday or "Nothing found", etc.
The application of offering both would be so that most developers would get the birthdate of the current user so that it can be applied to that session. To extend my example: A user logs in, the developer wants to be able to have "Happy Birthday" if it is applicable. The owners of the service/data don't want the developer's client to have any access, real or conceptual, to anything about the user, even their log in, they just want to accommodate the developer's goal, as it is really nice. The developer doesn't want to be responsible for potentially having access to anything, he just wants to be nice.
Version two is available for some user-support groups. They actually need to look up birthdates of users who call in so that they can confirm that the user's are old enough to, let's say, rent a car. They may even have to look up multiple user's to see who is most eligible out of the group to get the best deal.
So I guess the big question, finally, is whether or not these two methods can exist in the same service?
The protocol, at this point, is more likely to be SOAP-based, then RESTful, so simply having URLs that both resolve to the same service but simply offer different methods is probably not an option.
What I need, ideally, is a way to reveal operations in the WSDL based on role. Obviously the documentation given to either group would reflect only the operation appropriate for the role, but ideally the developer/client would a) not see any operations they shouldn't and b) receive the same type of response for trying to use a forbidden response as they would a non-existent one and c) most ideally, receive the former-mentioned error because for their role the operation really DOESN'T exist, not because the service took extra precaution in case the client did try (which it will, FYI, but I don't want that to be the first and only level of obfuscation).
Am I dreaming the impossible dream?
Quick Addendum
I should have been more specific about this, I realize. When I say "role-based" I am referring to service-accounts, not user-accounts. So in my hypothetical situation above, the user-service app that would all for querying any user ID would be using one service-account with the privs to do so, not checking the role of the agent logged in to the session (which would be done to get to the app, obviously, but not to the service).
Why not have two methods:
GetMyBirthday();
GetBirthday(string userName);
Any user can call the first method; only privileged users can call the second method. You use role-based authorization and reject calls to the second method from unauthorized users.
I don't see why you'd want to hide methods in the WSDL based on roles. In many cases you'll be accessing the WSDL only to build a proxy in a development environment, and won't need it at runtime.