I am designing an API using WSO2AM 2.0
My service is like : http://190.100.10.10:9000/abc/xyz/doPost<br>
I want to replace /abc/xyz/doPost by /<MY_CUSTOM_PATH>/doPost
How can I make a custom URL pattern to hide my original URL path from the service?
Like: http://<WSO2AM_GENERATED_HOST>/WSO2AM_CONTEXT/WSO2AM_VERSION/<MY_CUSTOM_PATH>/doPost
I have searched the docs, but I am not able to find any related tutorial.
If I put /abc/xyz/doPost it will get appended to the WSO2AM generated hostname.
What is "EDIT SOURCE" in the image below? Can it be used to do what I want? If YES, How??
There aren't anything like WSO2AM_CONTEXT or WSO2AM_VERSION. You can provide any value for the context and version. Version can be String, numbers, etc.
In your case, you can use abc as context and xyz as the version.
That is exactly the kind of URL you would get in WSO2 API Cloud: http://your.custom.url/api-name/version/context. See this tutorial for details: https://docs.wso2.com/display/APICloud/Customize+the+API+Store+and+Gateway+URLs
It might not be complicated...
In publisher interface, when you add/edit an API, in "Implementation" screen, just configure WSO2 APIM to point to "http://190.100.10.10:9000/abc/xyz" - this way, "/abc/xyz" will not be visible to your clients.
So in this case,
http://<WSO2AM_GENERATED_HOST>/WSO2AM_CONTEXT/WSO2AM_VERSION/doPost
will point to:
http://190.100.10.10:9000/abc/xyz/doPost
If you wanted to add additional custi=om paths, in the "Design" screen you attached, you can also add your "(MY_CUSTOM_PATH)/doPost" path there.
This way
http://<WSO2AM_GENERATED_HOST>/WSO2AM_CONTEXT/WSO2AM_VERSION/<MY_CUSTOM_PATH>/doPost
will point to:
http://190.100.10.10:9000/abc/xyz//<MY_CUSTOM_PATH>/doPost
(However, your backend services should also have "//doPost" implemented)
Related
In djangorestframework, there is a browsable api. But how do I show a user an entire bird's eye view of all the possible API calls that he/she can make? I can only see one at a time right now and the user would have to already know the correct URL beforehand
i.e.,
http://localhost:8000/users
http://localhost:8000/books
http://localhost:8000/book/1/author
Thank you!
The answer is as Klahnen said. Use this:
https://django-rest-swagger.readthedocs.io/en/latest/
It works out of the box for me and it is exactly what I was hoping for.
I still maintain, though, that the term browsable API implies that there is a table of contents available for consumers of your API to see. This app is a lifesaver and perhaps it should be included!
Django-Rest-Swagger as mentioned in the accepted answer is no longer maintained.
This is a good alternative
https://github.com/axnsan12/drf-yasg
Django-Rest-Swagger doesn't support OpenAPI 3.0 and is unlikely to support it soon, so if you want an actively maintained library that supports OpenAPI 3.0 then you should use drf-spectacular. It mostly works out of the box, and you can customize it a lot.
A side note:
Your api client needs access to the internet so that it gets the swagger UI or ReDoc from CDNs. Alternatively you can serve those static files from your service with an optional additional package, the drf-spectacular-sidecar
Registering filters with whiteboard.
Hi,
I'm trying to use a Servlet filter with a servlet. I'm using Pax-Web 3.0, Declarative services and whiteboard.
I have to declarative service components (one for the servlet and one for the filter), and it seems to work fine.
Looking at the documentation I see the following sentence:
For URL Patterns, the pattern registered must be already mapped,
either as Resource or a Servlet alias - e.g there should already be a
Resource or aServlet registered to the path /foo. For Servlet names,
the names used should have been the name that has been explicitly
given to the Servlet (as servlet-name), when registering.
How can I guarantee that in a whiteboard setting? I have no idea when the servlet actually gets registered. I guess I can list the servlet as a dependency of the filter, but that makes it tricky to use the filter for multiple servlets.
Is there a better way?
regards, Frank
It seems highly unlikely that this is an issue. I expect that the sentence from the documentation indicates that your filter just never get called when there is no destination for the path. I.e. the filter is only called when there is a valid destination (a resource or servlet). A basic aspect of the whiteboard is that you should not care about these issues. It is the responsibility for the whiteboard to handle the http service, the filters, and the servlets in any possible registration order. If not ... it needs a serious issue raised.
I have not looked at the code but I am a heavy user of the whiteboard + filter + servlet + DS and never have seen an issue.
I'm basically trying to make a REST call to the artifactory to get json response about the repositories.
My URL is something like this "http://127.0.0.1:8081/artifactory/api/storage/deploy/" where deploy is my repository.
Now i want to get the information about all the repositories whose name starts with - deploy .
How to modify the url in-order to get the info about the repositories with name starts with deploy??
Is it possible to do this, without getting all repositories name and then filtering?
Thanks.
I suppose this is not a java question, rather a question of your rest service supporting such behaviour. I.e your rest api must provide a method to get a list of all the repositories by regexp.
I don't think this can be solved by means of java in any way other than bruteforcing links.
I've been using django-auth-ldap for a while to auth against a single server (AUTH_LDAP_SERVER_URI in settings.py). There have been some changes in my organization recently, and I now need to be able to check against two different LDAP servers (actually: Active Directory, but I don't think that comes into play here). Unfortunately there is not a single location that has all of the user info I need.
Is there any way I can configure django-auth-ldap to check against more than 1 server? The documentation seems to assume a single server/URI. I'd also entertain ideas outside of django-auth-ldap, but I'd really like to stick with it if possible because it keeps things simple.
You would need to extend the custom auth handler to take an iterable for servers to check against and just step through them.
There is nothing stopping you from checking any number of directories for the information you need - there is no limitation in the underlying libraries.
django-auth-ldap 1.1 (just released) allows you to easily define multiple subclasses of the authentication backend that use different collections of settings. See http://packages.python.org/django-auth-ldap/#multiple-ldap-configs.
Preface
We are providing customers with our service API.
Each customer has own subdomain (e.g. sergii.ourwebsite.com) and own WSDL URL, it looks like http://sergii.ourwebsite.com/api/bsapi.cfc?wsdl
Also, all the websites (including API, of course) using the same codebase.
Problem
Say, two applications on same CF-server. This can easily happen, because some of customer websites are hosted on our servers.
Both trying to use own API WSDL, say:
http://sergii.ourwebsite.com/api/bsapi.cfc?wsdl
http://galashyn.ourwebsite.com/api/bsapi.cfc?wsdl
And here come the problems.
When second website tries to register the web-service, CF throws an error:
Name:
https://galashyn.ourwebsite.com/api/bsapi.cfc?wsdl.
WSDL:
https://galashyn.ourwebsite.com/api/bsapi.cfc?wsdl.
org.apache.axis.wsdl.toJava.DuplicateFileException:
Duplicate file name:
/opt/coldfusion8/stubs/WS1985941973/api/Bsapi.java.
Hint: you may have mapped two
namespaces with elements of the same
name to the same package name. It is
recommended that you use a web browser
to retrieve and examine the requested
WSDL document to ensure it is correct.
If the requested WSDL document cannot
be retrieved or is dynamically
generated, it is likely that the
target web service has programming
errors.
Problem is that both of them are using same WSDL namespace, built from CFC path:
<wsdl:definitions targetNamespace="http://api">
Current solution
The only working solution for us is using the CFC aliases, like:
http://galashyn.ourwebsite.com/api/v1n1/bsapi.cfc?wsdl
http://galashyn.ourwebsite.com/api/v1n1/bsapi.cfc?wsdl
Each this CFC extends the parent like this:
<cfcomponent output="false" extends="api.bsapi">
<!--- this component used to extend base api version 1.x --->
</cfcomponent>
They produce different namespaces, which can be used without problems -- own namespace for each application:
<wsdl:definitions targetNamespace="http://v1n1.api">
<wsdl:definitions targetNamespace="http://v1n2.api">
This is pretty dumb workaround, but it works for now.
Other solution would be to use the single API sub-domain and identifying the customers by some key (we are already using them for security purposes), but it has serious negative problems for us because of some legacy code.
Please note that I don't know Java, so many specific advices are not so clear for me.
Google shows that this problem exists for years, but I can't find the smart solution.
So maybe here?
I can not "place the WSDL at a common URL for all customers" for now and I've explained why: because I have to use the sub-domains. If you know the way to put the WSDL at one URL and make service requests to another -- please tell me.
A WSDL is just an XML document that describes the web service. You can write (customize) it using CFML. For instance:
http://subdomain.domain.com/api/wsdl.cfm?api=bsapi&customer=subdomain
Then just copy the WSDL generated by CF, and use it as a template for your custom WSDL page. Replace the parts of the WSDL that are subdomain-specific and return the XML document. Be mindful of whitespace (perhaps see CFSilent, CFSetting), and consider using CFHeader to set the mime type to "text/xml".
Do all the customers use the same WSDL? Then place the WSDL at a common URL for all customers.
I also think you need to find out exactly what the error message means. I don't see where it has anything to do with the URL being used. If it had mentioned the URL of another customer, I'd have understood.
Part of this may be due to my lack of understanding of how CF works. In particular, what is this "registering web services" that triggers the problem when two customers do it?
Did you realize that the URL in the <soap:address/> element in the WSDL is only a hint? In many clients, it can be overridden. In a .NET client, just set the Url property of the proxy class. This should allow you to have a single WSDL at a single location, and yet have your customers each reference the proper subdomain, assuming there's some way to convey that information to them. For instance, if there is a way for you to know which customer is making the call, then perhaps you could receive calls on one URL and then redirect to the proper URL, or else use a SOAP Routing infrastructure to route to the correct one.
I hope you are not changing the namespaces from one customer to another. Namespaces have nothing to do with URLs, even if they happen to look like URLs.
There is a namespace attribute for the cfcomponent tag. You should be able to use this, along with cgi.host_name (? I'm at home, without docs) to specify a namespace that matches the subdomain being queried.
Something like:
<cfcomponent namespace="http://#cgi.host_name#/api/v1n1/bsapi.cfc">
Have caught this error message when tried to CFINVOKE webservice from localhost by test script located on same localhost (but in different folder). Sounds 'buggish' for me.