I'm new to IBM BPM. I'm trying to create a web service for a class i'm taking but the instructor/site architect is unavailable at the moment.
Is there some way to determine the different types of RESTful calls available at a particular IBM BPM url?
My understanding is, that you would like to see which calls are supported by the IBM BPM REST API, is this correct?
You can discover the calls via the REST API Tester which can be found by the following URL:
http://{host}:{port}/bpmrest-ui
In this web-interface you can see different REST APIs, calls and you can build your own rest services with the provided input forms.
Source and further documentation: http://www.ibm.com/developerworks/websphere/library/techarticles/1108_thaker/1108_thaker.html
Related
I was surfing on internet for solutions and tools related to the API Layer and I find a company (maybe a startup) that is developing an ecosystem that allow to "virtualize the API Layer" (at the moment only in .net Core). It seems they allow to don't code the Api layer, don't write documentation of endpoints, don't writeE2E test (automatically inferred), change behaviour of endpoints at runtime and reuse the entire stack in another project. Do you think is it really possible something like this and useful in the world of API development? thanks
If I understand the question, your wondering about setting up an API layer with just the endpoints, but the endpoints have empty logic in them, right?
If so, then yes its possible to do this with a variety of tools. One tool I use is Postman, which allows you to setup a "skeleton" API you can call for design/testing purposes.
It allows standing up a mock server that hosts your skeleton API, in which any consumer can hook into.
I'm about to start a project where we have a back-end service to do long-winded processing so that our ASP.NET website is free to do quicker requests. As a result I have been reading up on services such as WCF and Web API to get a feel for what they do. Since this back-end service will actually be made up of several services communicating to each other and will not be publicly available to our customers, it seems that WCF is the ideal technology for this kind of scenario.
But after doing a lot of research I am still confused as to the benefits and differences between WCF and Web API. In general it seems that:
If you want a public and/or a RESTful API then Web API is best
WCF can support far more transports than just HTTP so you can have far more control over them
Web API development seems easier than WCF due to the additional features/complexity of WCF
But perhaps my question boils down to the following:
Why would a REST service be more beneficial anyway? Would a full blown WCF service ever be a good idea for a public API? Or is there anything that a WCF service could provide that Web API cannot?
Conversely, if I have a number of internal services that need to communicate with each other and would be happy to just use HTTP as the transport, does Web API suddenly become a viable option?
I answered a couple of related questions:
What is the future of ASP.NET MVC framework after releasing the asp.net Web API
Should it be a WebAPI or asmx
As an additional resource, I would like to recommend you to read:
http://www.codeproject.com/Articles/341414/WCF-or-ASP-NET-Web-APIs-My-two-cents-on-the-subjec
If you want to learn more about REST, check this Martin Fowler article
Summaring up:
As far as I know, both technologies are being developed by the same team in Microsoft, WCF won't be discontinued, it will still be an option (for example, if you want to increase the performance of your services, you could expose them through TCP or Named Pipes). The future is clearly Web API
WCF is built to work with SOAP
Web API is built to work with HTTP
In order to take the correct choice:
If your intention is to create services that support special scenarios – one way messaging, message queues, duplex communication etc, then you’re better of picking WCF
If you want to create services that can use fast transport channels when available, such as TCP, Named Pipes, or maybe even UDP (in WCF 4.5), and you also want to support HTTP when all other transports are unavailable, then you’re better off with WCF and using both SOAP-based bindings and the WebHttp binding.
If you want to create resource-oriented services over HTTP that can use the full features of HTTP – define cache control for browsers, versioning and concurrency using ETags, pass various content types such as images, documents, HTML pages etc., use URI templates to include Task URIs in your responses, then the new Web APIs are the best choice for you.
If you want to create a multi-target service that can be used as both resource-oriented service over HTTP and as RPC-style SOAP service over TCP – talk to me first, so I’ll give you some pointers.
One combersome bit of WCF is the need to generate new client proxys when input and/or output models change in the service. REST services don't require proxys, the client simply changes the query string sent or changes to parse and/or use the different output.
I found the default JSON serializers in .Net to be a bit slow, I implemented http://json.codeplex.com/ to do the inbound and output serialzation.
WCF services are not that complex, REST services can be equally challenging as you're working within the confines of HTTP.
ASP.net Web API is all about HTTP and REST based GET,POST,PUT,DELETE with well know ASP.net MVC style of programming and JSON returnable; web API is for all the light weight process and pure HTTP based components. For one to go ahead with WCF even for simple or simplest single web service it will bring all the extra baggage. For light weight simple service for ajax or dynamic calls always WebApi just solves the need. This neatly complements or helps in parallel to the ASP.net MVC.
Check out the podcast : Hanselminutes Podcast 264 - This is not your father's WCF - All about the WebAPI with Glenn Block by Scott Hanselman for more information.
Should I leverage an ASMX service or the ASP.NET Web API for my two simple API's?
I want to create two simple APIs in my ASP.NET MVC project. One takes in 3 parameters (currentUserID, DataType, ActionName). It returns them and an XML string of the data they have requested. The API is consumed by client-side JavaScript code. The other API receives an XML string and uses that on the server side to perform actions on the database.
I just answered a related question:
What is the future of ASP.NET MVC framework after releasing the asp.net Web API
Basically, the frameworks provided by Microsoft to develop Web Services are:
ASMX. XML Services based on SOAP.
WCF. Web services based on SOAP. These services were the evolution of the traditional ASMX services and basically they focused to separate the service itself from the transport protocol. That's why you can expose the same service using several endpoints and therefore several protocols (TCP, HTTP, Named Pipes, MSMQ, HTTPS). This flexibility came with the configuration problem. One of the main complaints in the community about the WCF is the tedious and extensive configuration
WEB API. Based on HTTP not in SOAP. This new API is a new framework to create services. The main difference with the other two predecesors, is the fact that it's based on HTTP and not on SOAP, therefore you can use several HTTP features like:
It contains message headers that are very meaningful and descriptive - headers that suggest the content type of the message’s body, headers that explain how to cache information, how to secure it etc.
use of verbs to define the actions (POST, PUT, DELETE..)
it contains a body that can be used to send any kind of content
It uses URIs for identifying both information paths (resources) and actions
WEB API is focused on writing services to expose them via HTTP (only on HTTP at the moment). If you want to expose your service using another protocol, then you should consider using WCF.
WEB API is based on MVC (if you want to know the reasons why it's based on MVC, they are simple)
Another goal of the WCF Web APIs was to incorporate known concepts that would help developers to overcome some of the drawbacks they faced with WCF, such as huge configurations, overuse of attributes, and the WCF infrastructure that did not support testing well. Thus the Web APIs used IoC, enabled convention-over-configuration, and tried to offer simpler configuration environment.
ASP.NET MVC infrastructure with its elegant handling of HTTP requests and responses, and its support of easy-to-create controllers seemed like the proper way to go for creating this new type of services.
Take the following points into consideration to choose between WCF or WEB API
If your intention is to create services that support special scenarios – one way messaging, message queues, duplex communication etc, then you’re better of picking WCF
If you want to create services that can use fast transport channels when available, such as TCP, Named Pipes, or maybe even UDP (in WCF 4.5), and you also want to support HTTP when all other transports are unavailable, then you’re better off with WCF and using both SOAP-based bindings and the WebHttp binding.
If you want to create resource-oriented services over HTTP that can use the full features of HTTP – define cache control for browsers, versioning and concurrency using ETags, pass various content types such as images, documents, HTML pages etc., use URI templates to include Task URIs in your responses, then the new Web APIs are the best choice for you.
If you want to create a multi-target service that can be used as both resource-oriented service over HTTP and as RPC-style SOAP service over TCP – talk to me first, so I’ll give you some pointers.
For a more detailed comparison:
http://www.codeproject.com/Articles/341414/WCF-or-ASP-NET-Web-APIs-My-two-cents-on-the-subjec
It seems you are really doing much with Views so I think Web API would be more concise solution at this point.
If possible, I would use an Web Api Controller in mvc4. You can return an generic ienumerable list or model and it will automatically output the data to whatever format is requested such as xml or json. Its pretty amazing.
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
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.