Help understand web services and REST

Question

I really wanted to ask this question, but took the time to do it now.

In any case, we discussed web services (yes, these traditional SOAP-XML response services) and RESTful services (which now have many developers).

I feel that although I understand the concept of REST in general, I need to know more. I think one of the best ways to fully cover this is to show that it is really better (emphasis on **, because the subjective word is better), like what was being done at the moment.

Consider the following simple traditional codes: (This instance is copied from a corporate application with Oracle as a backend. The database, to a large extent, I think, does not matter, since you could easily switch between SQL Server or Oracle or any database on this) .

myWebService.asmx.cs

namespace MyApplication { public class myWebService : System.Web.Services.WebService { private classEmployee _emp = new classEmployee(); [WebMethod] public string GetEmployees() { string EmployeeData = string.Empty; EmployeeData = _emp.GetEmployees(); return EmployeeData; } } } 

classEmployee.cs

 using System; using System.Collections.Generic; using System.Data; using System.Globalization; using System.Data.OracleClient; namespace MyApplication.App_Code { public class classEmployee { private DataAccess _da; public string GetEmployees() { string employeeData = string.Empty; string cmd = string.Empty; OracleCommand oraCmd = new OracleCommand(); DataSet ds = new DataSet(); try { cmd = "SELECT * FROM Employees"; oraCmd.CommandType = CommandType.Text; oraCmd.CommandText = cmd; ds = (DataSet)_da.ExecSQLQueryCmd(oraCmd, DataAccess.ResultType.DataSet); employeeData = ds.GetXml ds.Dispose(); } catch (Exception ex) { employeeData = "Error: " + "Getting Employees [GetEmployees]" + Environment.NewLine + "Details: " + Environment.NewLine + ex.Message; } return employeeData; } } } 

DataAccess.cs

 using System; using System.Collections; using System.Configuration; using System.Data; using System.Data.OracleClient; namespace MyApplication.App_Code { public class DataAccess { private OracleConnection oraConn; private String connString; public enum ResultType { DataReader = 0, DataSet = 1, DataTable = 2 } public DataAccess() { connString = System.Configuration.ConfigurationManager.ConnectionStrings["AppConnectionString"].ConnectionString; } public object ExecuteSQLCommand(OracleCommand oraCommand, ResultType ReturnType, string TableName = "") { OracleDataAdapter oraDataAdapter = new OracleDataAdapter(oraCommand); oraConn = new OracleConnection(sConnectionString); try { oraConn.Open(); oraCmd.Connection = oraConn; oraCmd.CommandType = CommandType.Text; switch (ReturnType) { case ResultType.DataReader: OracleDataReader oraDataReader = null; oraDataReader = oraCmd.ExecuteReader(); return oraDataReader; case ResultType.DataSet: DataSet ds = new DataSet(); oDataAdapter.Fill(ds); oraConn.Close(); oraConn.Dispose(); return ds; case ResultType.DataTable: DataTable dt = new DataTable(); if (!string.IsNullOrEmpty(TableName)) dt.TableName = TableName; oDataAdapter.Fill(dt); oraConn.Close(); oraConn.Dispose(); return dt; } } catch (OracleException oException) { throw oException; } finally { oDataAdapter.Dispose(); oDataAdapter = null; oraCmd.Dispose(); } return null; } public int ExecuteSQLNonQueryCommand(OracleCommand oraCommand) { // This will execute any NON-QUERY command. //Trimmed for Brevity purposes.. } } } 

The above code is pretty clear. Call the web service and receive the received data in XML format. To execute commands without a request, simply replace the command line passed in the command object and call the required method in the DataAccess.cs class.

I am already stunned by different opinions about why, at least, the above should be avoided and instead call for RESTful type calls. But I have not seen anything that at least helps to transform this code to at least cover the RESTful architecture.

I am sure many people use this (remember, I am still using a lot of this currently), based on the reason that:

• He works.
• Ease of implementation, support and management.
• There are so many people running the database in SQL commands that the ability to use these SQL chops that we use in the SQL editor is easy in the application - this is a big sigh of relief. Why would you use ORM when you can simply implement all your multiple queries (including stored procedures) using the example above.
• Most of the code samples available for data-related applications show the same pattern as above (the data set is populated from the Command object and returned as a DataSet or XML, etc.).

For someone to agree on what people call "best practice" in this area of ​​coding, you need to show why it is better and how much easier it is to do such a thing over what has been tried and tested for work.

If I can ask our fellow experts to show me how to convert them, and some explanation of why converting to REST would be better (via code), then I would be more than grateful for that.

Rate your entries. Thanks.

Additionally: I just want to note that although this is correct, I have some doubts that this approach is best after reading this article:

http://www.codeproject.com/Feature/WeirdAndWonderful.aspx?msg=4324770#xx4324770xx

In the article above, as I commented on the above, “I found this in the web service that I am updating. It’s hard for me to find something wrong with this.”

I am also trying to establish what is REALLY wrong with this, as I am in a binding.

Let me give you some situations:

• The Client / Client asks you for an application that requests information stored in the database.
• Come up with a solution using the method described above. Customer requirements are provided. The solution is reliable, fast and convenient.

So, in essence, another question I want to ask is what is really wrong with the code above?

Answer 1

To convert it, although this does not fit my head, it will look something like this.

 namespace MyApplication { public class myWebService : System.Web.Services.WebService { private classEmployee _emp = new classEmployee(); [HttpGet] public string GetEmployees() { string EmployeeData = string.Empty; EmployeeData = _emp.GetEmployees(); return EmployeeData; } } } 

And you can return this line to everything that is easily converted by the consumer. If this is JavaScript, I would recommend JSON, since it was native.

Tell us about ReST in a minute. The part that I find most fun about ReST is that the old-fashioned ASMX services were ReSTful. But, since the IT industry has a problem accepting the fact that the older technology may have been more correct, all the time they had to call it something new and new.

They did this with the term Client/Server . IBM performed Client / Server operations several years before Microsoft and said we needed to bring everything down to the PC. Well, when it became less popular because deployment was a nightmare , they realized, about a person, we need to get back to what IBM has been doing all this time. Large servers, dumb clients, and simple deployments. But they could not call it, because the industry would not agree with it, and Microsoft did not want it, therefore they called it The Cloud (here we insert bum, bum, bum music).

So go to SOAP. People wanted to be able to transfer complex objects over the wire, rather than deserializing them, and they wanted protocol flexibility. Well, SOAP gave you both, Microsoft creates client presentation and deserialization, and the WCF layer provides real protocol flexibility, while ReST can only be transmitted over HTTP because it uses standard verbs.

So, the real answer to your question is: what do you need?

• SOAP is heavier and often less efficient on very large datasets than ReST, since it is not a native operation for the browser and . But then again, how much data do you really need to transfer to the client?!?
• Do you want to create one click on the client model? Then use SOAP.
• Do you want to make the API more accessible to other programming paradigms? Then use reST.
• Do you want to follow the rest of the industry at the moment? Then use reST.

There is much more discussion, but you should start. ReST is no better than SOAP, it is different, and it solves a different set of problems. Do not let yourself or others tell you the law of the instrument .