How to generate the API of my Site ... www.volvobusesindia.com so that i can provide my site API to agents so that cthey can vbook tickets using our API ?
i want the bus booking search box appear in the site will be displayed in others website ?
You need to either create WCF SOAP based webservices or WCF REST based services.
You then need to publish these on a web server so it can be accessed by the agents.
You need to document all the API methods and parameters so it is easy for the agents to use your services.
You also need to have an authentication/authorization system in place to ensure your services are used only by the authorized agents.
Actually, you have to have the 'API' first, and then you build your website as a front-end to the API.
An API is just a set of public methods. That's all. For a desktop application, these methods will be in a dll. For a web application these methods will be Web Service, or HTTP Get or HTTP Post methods. API is just a nice name for this.
You then document all the calls available. You use the document to build your website, and you give the documents to others so they can build their website.
The API is the foundation of the system.
Related
I want to use the API to get a map tile and a routing API with different application codes and application identifiers. So that with the credentials for routing, I could not use the API to get tile maps and vice versa. How can I get these credentials?
Please see below Legacy Modules in the web pages.
https://developer.here.com/documentation/maps/topics/migration.html
App Id and app code can be uniquely generated for each project. So if you intend to use different app id and code for different apis then you have to create another Project in the project plan page. App ID and Code provides access to all the apis in Here(as per design) and it is up to your code to restrict the usage to particular api. Here only provides domain whitelisting option for any app credentials.
I hope this help.
API Keys in web side context are never secured, this can be a big problem if API services are paid for. How to solve this problem in Azure Cognitive Service context ?
I assume you are referring to not exposing the keys to the end user who is browsing to your website, as opposed to securing the keys on the webserver itself from another admin on the server.
This isn't really a Cognitive Services question, but a question generic to any secrets you want to keep when hosting a website (or creating a mobile app, or really any app that uses some sort of key or password).
The short answer is, don't give the key to the client, which means that the client can't directly make the call to Cognitive Services, and you have to have code running on your web server that makes the call.
Generally you would do one of two things:
Code running on your web server would make the call to Cognitive and then process and display relevant results to the user via the webpage.
Your web server would expose an API, and then you would have client side script call your API. Your API internally would call the Cognitive Services API and return the data where the client side script would process and display the results.
You can also find similar info at How to protect an API Key when using JavaScript?, or a web search for something like 'web development protecting api keys javascript'.
I'm creating a client for a web site, which will scrap this website for data.
What I would like to do, is to design API of this client in the way, that it could be used without modifications, if a web API was created in the future.
Currently the website does not provide any web API. It does use AJAX, so parts of its functionality can be easily reused within the client.
The biggest issue I'm dealing with now, is that some data is not identified by integers. Instead a string is used, which describes name of the object. So, if I were to use integer in the abstraction and string in web scraping implementation, I would have to use some sort of mapping between integers and strings.
So my question is: should I continue trying to create a "perfect" abstraction for the client? Or should I just create web scraping client and if/when web API is available, I would create a new client?
If I understand what you are asking, you are wondering if it is worthwhile to create in intermediate API which your client talks to, and then the intermediate API does the web scraping:
client-->API-->Web Site
Then when the Web site creates an API, your API would talk to it without modifications to the client:
client-->API-->Web Site API
versus just continuing to have the client scrape the web site directly until the web site provides an API:
client-->Web Site
And then have the client talk to the API:
client-->Web Site API
It's difficult to give you an answer without understanding your situation, but here are some considerations that can help you make decision:
How difficult will it be to update the client? If there are many clients or its difficult to update them, then hiding some logic in your own API makes sense.
How likely is it that the Web Site API will match directly to your API? You may need to change your client anyway if your API doesn't fit with the web site API.
Will some other website provide a better or cheaper service? If so you could switch to that other website with less impact on the client by using an API.
I am building a web site, and have created an API for it using WebAPI. The API is secured using OAuth v1 using DotNetOpenAuth and all is working fine with an iPhone app calling into the API. I would like to go back and make the pertinent parts of the web use the API too so that evrything always goes through the API.
The part I am slightly confused about though is if I make my website login go through the API, set up the web site as an OAuth Consumer, get an OAuth token for the current user, should I then in the web site code make a http call into WebAPI on the same box to call the API passing my OAuth token? (in the HTTP Auth header)
It seems like quite an inefficient way to get the web site to call the API as all calls require the server side to make a HTTP call as well, doesn't sound particularly scalable to me? I am not sure of the alternatives though given I want to use OAuth to secure the API.
This is a good question and keeps coming up (since you clearly realise the overhead of having another network-bound hop):
Do I need to consume my own API in my ASP.NET MVC or bypass API and go straight to the business logic?
I have tried to explain this in a blog post (towards the end of the post). However, in short: it depends. If your API and MVC site are part of the same application, then they sit next to each other as they are both the Presentation Layer - as I explain in the post. If, however, your API is the presentation layer of an SOA service and used by several clients including your MVC site, then yes it has to be separate.
In your case, I am inclined to put the MVC side by side your Web API - accessing the same business layer. And I believe this also fixes the OAuth issue you are having.
I currently have a webforms asp.net using entity framework to do all the CRUD operations.
I need to create a public facing API for my website.
I need the following from an API:
Authentication of clients consuming the API
Usage Logging, to make sure there is no abuse etc
Throttling as an added extra to make sure one person doesn't overload the API.
Preferably the return data should be able to return in either JSON or XML, based on a flag the calling client uses.
I am looking for any guidance as the the most efficient way to create a public API to cater for these requirements. Suggested Books, Links, suggestions are all and any thing else are welcome.
Doing this in code is definitely do-able, but it's fairly involved for all those functions. An easier way is to use something like 3scale (http://www.3scale.net) which does all of this out of the box (you can issue API keys, rate limit them, get analytics for the API + create a developer portal). Setup is via a code library you drop into your system in general (libraries are here: (https://support.3scale.net/libraries) or there's an API or lastly set up Varnish as an API proxy in front of your application using this mod: https://github.com/3scale/libvmod-3scale/.
For the data return type, typically you would switch this by having .json, .xml in the API requests and handle this as a content type within the code.
Use WebAPI:
ASP.NET Web API is a framework that makes it easy to build HTTP
services that reach a broad range of clients, including browsers and
mobile devices. ASP.NET Web API is an ideal platform for building
RESTful applications on the .NET Framework.
http://blogs.msdn.com/b/henrikn/archive/2012/02/23/using-asp-net-web-api-with-asp-net-web-forms.aspx
http://www.asp.net/web-api/overview/hosting-aspnet-web-api/using-web-api-with-aspnet-web-forms
http://www.beletsky.net/2011/10/integrating-aspnet-mvc-into-legacy-web.html