I am query for a long time now.Where exactly we need to use WEB API and where should we use WCF restful services. What ever we want to achieve in WEB API we are able to achieve in WCF Rest. I tried to dig into answers but i got we need to do extra setting in wcf like URI templates,Contracts,endpoints. But its more on settings , but I wanted to known the real reason behind using WCF Restful Services.
Web Service
It is based on SOAP and returns data in XML format.
It supports only the HTTP protocol.
It is not open source but can be consumed by any client that understands XML.
It can be hosted only on IIS.
WCF
It is also based on SOAP and returns data in XML format.
It is the evolution of web services (ASMX) and support various protocols like TCP, HTTP, HTTPS, Named Pipes, MSMQ.
The main issue with WCF is its tedious and extensive configuration.
It is not open source but can be consumed by any client that understands XML.
It can be hosted with in the application or on IIS or using window service.
WCF REST
To use WCF as a WCF REST service you have to enable webHttpBindings.
It supports HTTP GET and POST verbs by [WebGet] and [WebInvoke] attributes respectively.
To enable other HTTP verbs you have to do some configuration in IIS to accept request of that particular verb on .svc files.
Passing data through parameters using a WebGet needs configuration. The UriTemplate must be specified.
It supports XML, JSON and ATOM data format.
Web API
This is the new framework for building HTTP services the easy and simple way.
Web API is open source an ideal platform for building RESTful services using the .NET Framework.
Unlike a WCF REST service, it use the full features of HTTP (like URIs, request/response headers, caching, versioning, various content formats).
It also supports the MVC features such as routing, controllers, action results, filter, model binders, IOC container or dependency injection, unit testing that makes it more simple and robust.
It can be hosted within the application or on IIS.
It is a light weight architecture and good for devices which have limited bandwidth like smart phones.
Responses are formatted by Web API’s MediaTypeFormatter into JSON, XML or whatever format you want to add as a MediaTypeFormatter.
Choosing between WCF or Web API
Choose WCF when you want to create a service that should support special scenarios such as one way messaging, message queues, duplex communication etc.
Choose WCF when you want to create a service 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 transport channels are unavailable.
Choose Web API when you want to create a resource-oriented services over HTTP that can use the full features of HTTP (like URIs, request/response headers, caching, versioning, various content formats).
Choose Web API when you want to expose your service to a broad range of clients including browsers, mobiles, iPhone and tablets.
For more details you can refer to http://www.c-sharpcorner.com/UploadFile/8a67c0/who-is-winner-web-api-or-wcf/.
Related
I currently have a mobile application talks to a GraphQL API service which terminates SSL and then proxies requests to gRPC services. The gRPC services only talk to each other via gRPC.
This system works okay but writing all of the boilerplate to plumb the gRPC APIs through the GraphQL layer to the client is tedious and can be error prone.
I’ve started exploring the idea of talking directly to the backend via gRPC as the tooling has improved substantially over the last few years.
One issue I’m still wondering about, though, is the best way to disambiguate APIs only meant to be called internally by other services from those callable publicly by the native client.
There is also a third category, “hybrid” APIs where it can be called either internally or externally.
Examples —-
Internal: Sending an SMS via Twilio
Public: Log in to account
Hybrid: Update whether an inbox item is read (both from the app when opening a conversation and on the backend when a message is sent)
One option I thought of was an interceptor that passes along a context to indicate if the request is internal or public and use this in the code to return an error or perform additional validation on public requests.
Another option is creating an API service which is still gRPC but fulfills the same purpose as the GraphQL API service.
A third option is disambiguating public and internal services at an organizational level which might require duplicating some APIs that exist for both.
Are there other options I’m unaware of? How have you tackled this issue?
I'm going to develop a Banking application that will send and receive information to mobile devices of bank account holder. I want to use REST api of Spring framework for this purpose. Is there any bank that uses RESTful api for applications?
Does RESTful api provide enough security for this purpose?
Or should I stick to use SOAP web service?
I know, this question is asked several times. But I want to concentrate on feasibility of REST api for Banking domain.
Most banks still use SOAP for integration, but you could find examples of companies like Visa or Paypal which expose their api in a RESTful way.
There is a key difference between using SOAP with WS-Security and a REST api with SSL, thats WS-Security which offers end-to-end security (offers confidentiality and integrity protection from the source of the message to the receiver).
What we are dealing here is security at two different levels: HTTPS applies at the transport layer (which you could apply to REST or SOAP service) and WS-Security applies at the application layer.
But now you could deal with REST using OAuth2, check on how Paypal uses it here.
Another question related: Secure Web Services: REST over HTTPS vs SOAP + WS-Security. Which is better?
Yes, it is as secure (or insecure) as any other method including SOAP. You still have to follow all best practices while writing your application (using https everywhere, encrypting sensitive data, making sure you don't write sensitive data to logs in plain text, and so on). It is best to discuss with the Security team for your bank/company, they'll usually have a set of requirements that you need to follow to secure your application.
From security perspective REST over HTTPS is good enough unless you need end-to-end security or you have compliance limitations.
If your banking mobile application will communicate through any intermediates (this could be NFC, Bluetooth Low Energy enabled POS e.g.) then I would recommend considering end-to-end security depending on risks and sensitivity of the information you are planning to send. Unfortunately there is no end-to-end security mechanism I can recommend for banking app except WS-Security. I had a look at many solutions like JSON Web Encryption (JWE), Javascript Object Signing and Encryption (JOSE), OAuth 1.0 Signature and others. I've found no solution which provides end-to-end security with respect to Integrity, Confidentiality, Authenticity for RESTful web-services out-of-the-box. The reason is that RESTful web-services are assumed to work always over HTTP and thus they will be protected with HTTPS. So if you need end-to-end security it's a good point to think about SOAP and WS-Security.
Another reason to think on WS-Security could be compliance regulations like PCI DSS. Then you can reduce compliance scope with end-to-end encryption of cardholder data. Good example is what Netflix guys did https://youtu.be/sYFDnGjNVrk. So investigate your compliance regulation if you have such before making a decision.
What are the advantages of using an HTTP Adapter in Worklight IBM to retrieve data from a Restful API instead of an ajax request? I think that using ajax is faster so why would one use such an adapter?
Take a look at the documentation and getting started modules.
Benefits of IBM Worklight adapters
Adapters provide various benefits, as follows:
Fast Development: Adapters are developed in JavaScript and XSL. Developers employ flexible and powerful server-side JavaScript to produce succinct and readable code for integrating with back-end applications and processing data. Developers can also use XSL to transform hierarchical back-end data to JSON.
Read-only and Transactional Capabilities: IBM Worklight adapters support read-only and transactional access modes to back-end systems.
Security: IBM Worklight adapters use flexible authentication facilities to create connections with back-end systems. Adapters offer control over the identity of the user with whom the connection is made. The user can be a system user, or a user on whose behalf the transaction is made.
Transparency: Data retrieved from back-end applications is exposed in a uniform manner, so that application developers can access data uniformly, regardless of its source, format, and protocol.
How can I access signalr hub via browser? I've created hub named "testhub" (using HubName property) and method "Hello" in it, so I want to access it smth like that: http://serverurl/signalr/testhub/Hello
SignalR is a real-time messaging framework and so a connection is first established using one of several higher level protocols over HTTP (WebSockets at best, long polling at worst) and then the Hub methods themselves are invoked by passing JSON formatted messages through that higher level protocol.
The example you're describing seems like you're expecting a request/response model and for that you are better off using a REST based technology like ASP.NET MVC or ASP.NET Web API.
So I created a TCP\HTTP server (IN C#). I want to give to it namespace on my 80's port near to other HTTP servers I have. How to do such thing (step - by step)?
Look at HTTP Server Tasks in MSDN spec:
Initialize HTTP service API, call HttpInitialize
Register URLs with HTTP.SYS, call HttpAddUrlToUrlGroup
Receive a request, call HttpReceiveHttpRequest
Send a response, call HttpSendHttpResponse
Cleanup after urself, call HttpRemoveUrl and HttpTerminate
There is a also a fully fledged application sample at HTTP Server Sample Application.
As you can clearly see, HTTP.SYS API is a C API intended for C applications. You shouldn't be using it from C#, and I'd recommend against pInvoking the entire API. Managed applications have the alternative of using HTTP modules and extend the ASP.Net processing. This avenue will take care of many details needed in a managed server, like activation, hosting, process monitoring and recycling and so on and so forth.
The way you would normally interact with http.sys is by registering an ISAPI DLL with IIS. This is a good starting-point.