Using WCF SOAP Services in .Net Core
یکی از وب سرویس‌های سایت name api، امکان تشخیص موقتی بودن ایمیل مورد استفاده‌ی جهت ثبت نام در یک سایت را فراهم می‌کند. آدرس WSDL آن نیز در اینجا قرار دارد. اگر مطابق معمول استفاده از سرویس‌های وب در دات نت، بر روی ارجاعات پروژه کلیک راست کرده و گزینه‌ی Add service refrence را انتخاب کنیم و سپس آدرس WSDL یاد شده را به آن معرفی کنیم، بدون مشکل ساختار این وب سرویس دریافت و برای استفاده‌ی از آن به یک چنین کدی خواهیم رسید:
متد isDisposable ارائه شده‌ی توسط این وب سرویس، دو پارامتر context که در آن باید API Key خود را مشخص کرد و همچنین آدرس ایمیل مورد بررسی را دریافت می‌کند. اگر به همین ترتیب این پروژه را اجرا کنید، با خطای Bad request از طرف سرور متوقف خواهید شد:
اگر به خروجی این وب سرویس در فیدلر مراجعه کنیم، چنین شکلی را خواهد داشت:
عنوان کرده‌است که api-key را، در درخواست وب خود ذکر نکرده‌ایم.
اگر همین وب سرویس را توسط امکانات سایت http://wsdlbrowser.com بررسی کنید، بدون مشکل کار می‌کند. اما تفاوت در کجاست؟
خروجی ارسالی به سرور، توسط سایت http://wsdlbrowser.com به این شکل است:
و نمونه‌ی تولید شده‌ی توسط WCF (امکان Add service reference در حقیقت یک WCF Client را ایجاد می‌کند) به صورت زیر می‌باشد:
از لحاظ اصول XML، خروجی تولیدی توسط WCF هیچ ایرادی ندارد. از این جهت که نام فضای نام مرتبط با http://schemas.xmlsoap.org/soap/envelope/ را به s تنظیم کرده‌است و سپس با استفاده از این نام، Envelope را تشکیل داده‌است. اما ... این وب سرور جاوایی دقیقا با نام SOAP-ENV کار می‌کند و فضای نام ns1 بعدی آن. کاری هم به اصول XML ندارد که باید بر اساس نام xmlns ذکر شده، کار Parse ورودی دریافتی صورت گیرد و نه بر اساس یک رشته‌ی ثابت از پیش تعیین شده. بنابراین باید راهی را پیدا کنیم تا بتوان این s را تبدیل به SOAP-ENV کرد.
برای این منظور به سه کلاس ذیل خواهیم رسید:
که پس از تعریف client به نحو ذیل معرفی می‌شوند:
توسط EndpointBehavior سفارشی، می‌توان به متد OnWriteStartEnvelope دسترسی یافت و سپس s آنرا با SOAP-ENV درخواستی این وب سرویس جایگزین کرد. اکنون اگر برنامه را اجرا کنید، بدون مشکل کار خواهد کرد و دیگر پیام یافت نشدن API-Key را صادر نمی‌کند.
کدهای کامل این مثال را از اینجا می‌توانید دریافت کنید.
var client = new SoapDisposableEmailAddressDetectorClient();
var context = new soapContext
{
//todo: get your API key here: http://www.nameapi.org/en/register/
apiKey = "test"
};
var result = client.isDisposable(context, "DaDiDoo@mailinator.com");
if (result.disposable.ToString() == "YES")
{
Console.WriteLine("YES! It's Disposable!");
} Additional information: The remote server returned an unexpected response: (400) Bad Request.
<html><head><title>Bad Request</title></head><body><h1>Bad Request</h1><p>No api-key provided!</p></body></html>
اگر همین وب سرویس را توسط امکانات سایت http://wsdlbrowser.com بررسی کنید، بدون مشکل کار می‌کند. اما تفاوت در کجاست؟
خروجی ارسالی به سرور، توسط سایت http://wsdlbrowser.com به این شکل است:
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns1="http://disposableemailaddressdetector.email.services.v4_0.soap.server.nameapi.org/">
<SOAP-ENV:Body>
<ns1:isDisposable>
<context>
<apiKey>test</apiKey>
</context>
<emailAddress>sdsdg@site.com</emailAddress>
</ns1:isDisposable>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope> <s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<s:Body xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<isDisposable xmlns="http://disposableemailaddressdetector.email.services.v4_0.soap.server.nameapi.org/">
<context xmlns=""><apiKey>test</apiKey></context>
<emailAddress xmlns="">DaDiDoo@mailinator.com</emailAddress>
</isDisposable>
</s:Body>
</s:Envelope> برای این منظور به سه کلاس ذیل خواهیم رسید:
public class EndpointBehavior : IEndpointBehavior
{
public void AddBindingParameters(ServiceEndpoint endpoint, BindingParameterCollection bindingParameters)
{ }
public void ApplyDispatchBehavior(ServiceEndpoint endpoint, EndpointDispatcher endpointDispatcher)
{ }
public void Validate(ServiceEndpoint endpoint)
{ }
public void ApplyClientBehavior(ServiceEndpoint endpoint, ClientRuntime clientRuntime)
{
clientRuntime.MessageInspectors.Add(new ClientMessageInspector());
}
}
public class ClientMessageInspector : IClientMessageInspector
{
public void AfterReceiveReply(ref Message reply, object correlationState)
{ }
public object BeforeSendRequest(ref Message request, System.ServiceModel.IClientChannel channel)
{
request = new MyCustomMessage(request);
return request;
}
}
/// <summary>
/// To customize WCF envelope and namespace prefix
/// </summary>
public class MyCustomMessage : Message
{
private readonly Message _message;
public MyCustomMessage(Message message)
{
_message = message;
}
public override MessageHeaders Headers
{
get { return _message.Headers; }
}
public override MessageProperties Properties
{
get { return _message.Properties; }
}
public override MessageVersion Version
{
get { return _message.Version; }
}
protected override void OnWriteStartBody(XmlDictionaryWriter writer)
{
writer.WriteStartElement("Body", "http://schemas.xmlsoap.org/soap/envelope/");
}
protected override void OnWriteBodyContents(XmlDictionaryWriter writer)
{
_message.WriteBodyContents(writer);
}
protected override void OnWriteStartEnvelope(XmlDictionaryWriter writer)
{
writer.WriteStartElement("SOAP-ENV", "Envelope", "http://schemas.xmlsoap.org/soap/envelope/");
writer.WriteAttributeString("xmlns", "ns1", null, value: "http://disposableemailaddressdetector.email.services.v4_0.soap.server.nameapi.org/");
}
} var client = new SoapDisposableEmailAddressDetectorClient(); client.Endpoint.Behaviors.Add(new EndpointBehavior());
کدهای کامل این مثال را از اینجا می‌توانید دریافت کنید.
سلام
نه مسلما در حد WCF service های کامل نمی‌تونید ازش انتظار داشته باشید و خروجی فقط SOAP messages است.
البته می‌تونید FORMAT = NONE را در تعریف end point لحاظ کنید و بعد خروجی را آن طور که دوست دارید فرمت کرده و ارائه دهید. (باید کد نویسی کنید)
ولی کلا در این حد که نیاز به یک هاست را برطرف می‌کند و خیلی سریع بدون کد نویسی آنچنانی یک وب سرویس در اختیار شما خواهد بود، واقعا کارآمد است.
نه مسلما در حد WCF service های کامل نمی‌تونید ازش انتظار داشته باشید و خروجی فقط SOAP messages است.
البته می‌تونید FORMAT = NONE را در تعریف end point لحاظ کنید و بعد خروجی را آن طور که دوست دارید فرمت کرده و ارائه دهید. (باید کد نویسی کنید)
ولی کلا در این حد که نیاز به یک هاست را برطرف می‌کند و خیلی سریع بدون کد نویسی آنچنانی یک وب سرویس در اختیار شما خواهد بود، واقعا کارآمد است.
- اگر با این نحو در جای دیگری سؤال بپرسید، به این دلایل با شما بدرفتاری خواهد شد. بهتر است یک حداقلی را رعایت کنید.
- شما قصد دارید به یک php soap server متصل شوید که چنین کاری با ابزار فوق امکان پذیر نیست اما ... فناوری NET Framework 2.0 ASMX WebServices. با این نوع soap serverها به‌خوبی کار می‌کند. برای اینکار یک برنامه‌ی کنسول دات‌نت فریم ورک قدیمی (4x) را درست کنید. بعد از منوی Add، گزینه‌ی Service reference را انتخاب کرده و آدرس مدنظر را وارد کنید. با کلیک بر روی دکمه‌های Go و Ok، یک فایل wsdl. برای آن تولید می‌شود.
- پس از تولید فایل wsdl به روشی که گفته شد، این فایل، در نگارش‌های جدیدتر دات‌نت، توسط پنجره‌ای که تصویر آنرا ارسال کردید، قابل استفاده‌است. نکته‌ی مهم آن، استفاده از دکمه‌ی browse در این پنجره‌است که قابلیت دریافت مسیر فایل wsdl تولید شده‌ی در قسمت قبل را دارد (و نه استفاده از دکمه‌ی Go).
قابلیت جالبی از SQL Server 2005 به بعد به این محصول اضافه شده است که امکان ایجاد یک وب سرویس بومی را بر اساس رویه‌های ذخیره شده و یا توابع تعریف شده در دیتابیس‌های موجود، فراهم می‌سازد. این قابلیت نیازی به IIS یا هر هاست دیگری برای اجرا ندارد و توسط خود اس کیوال سرور راه اندازی و مدیریت می‌شود.
توضیحات مفصل آنرا در MSDN می‌توانید ملاحظه کنید و در اینجا یک مثال عملی از آن را با هم مرور خواهیم کرد:
الف) ایجاد یک جدول آزمایشی به همراه تعدادی رکورد دلخواه در آن
CREATE TABLE [tblWSTest](
[id] [int] IDENTITY(1,1) NOT NULL,
[f1] [nvarchar](50) NULL,
[f2] [nvarchar](500) NULL,
CONSTRAINT [PK_tblWSTest] PRIMARY KEY CLUSTERED
(
[id] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
SET IDENTITY_INSERT [tblWSTest] ON
INSERT [tblWSTest] ([id], [f1], [f2]) VALUES (1, N'a1', N'a2')
INSERT [tblWSTest] ([id], [f1], [f2]) VALUES (2, N'b1', N'b2')
INSERT [tblWSTest] ([id], [f1], [f2]) VALUES (3, N'c1', N'c2')
INSERT [tblWSTest] ([id], [f1], [f2]) VALUES (4, N'd1', N'd2')
INSERT [tblWSTest] ([id], [f1], [f2]) VALUES (5, N'e1', N'e2')
SET IDENTITY_INSERT [dbo].[tblWSTest] OFF
CREATE PROCEDURE GetAllData
AS
SELECT f1,
f2
FROM tblWSTest
CREATE ENDPOINT GetDataService
STATE = STARTED
AS HTTP(
PATH = '/GetData',
AUTHENTICATION = (INTEGRATED),
PORTS = (CLEAR),
CLEAR_PORT = 8080,
SITE = '*'
)
FOR SOAP(
WEBMETHOD 'GetAllData'
(NAME = 'testdb2009.dbo.GetAllData'),
WSDL = DEFAULT,
DATABASE = 'testdb2009',
NAMESPACE = DEFAULT
)
توضیحات:
Ports در حالت clear و یا ssl می‌تواند باشد. همچنین برای اینکه با IIS موجود بر روی سیستم هم تداخل نکند CLEAR_PORT به 8080 تنظیم شده است. سایر پارامترهای آن بسیار واضح هستند. برای مثال تعیین دیتابیسی که این رویه ذخیره شده در آن قرار دارد و همچنین مسیر کامل دسترسی به آن دقیقا مشخص می‌گردند.
این وب سرویس هم اکنون آغاز به کار کرده است. برای مشاهده wsdl آن، آدرس زیر را در مرورگر وب خود وارد نمائید (PATH و CLEAR_PORT معرفی شده در endPoint اینجا بکار می‌رود):
http://localhost:8080/GetData?wsdl
د) استفاده از این وب سرویس در یک برنامه ویندوزی
یک برنامه ساده winForms را شروع کنید. سپس یک DataGridView را بر روی فرم قرار دهید (بدیهی است این مورد می‌تواند یک برنامه ASP.Net هم باشد و موارد مشابه دیگر). سپس از منوی پروژه، یک service reference را در VS2008 بر اساس آدرس wdsl فوق اضافه کنید (شکل زیر):
برای اینکه این مثال در VS2008 درست کار کند باید فایل app.config ایجاد شده را کمی ویرایش کرد. قسمت security آن را یافته و تغییرات زیر را با توجه به AUTHENTICATION مورد نیاز تغییر دهید:
<security mode="TransportCredentialOnly">
<transport clientCredentialType="Windows" proxyCredentialType="None"
realm="" />
<message clientCredentialType="UserName" algorithmSuite="Default" />
</security>
using System;
using System.Data;
using System.Windows.Forms;
namespace WebServiceTest
{
public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
}
private void Form1_Load(object sender, EventArgs e)
{
ServiceReference1.GetDataServiceSoapClient data =
new ServiceReference1.GetDataServiceSoapClient();
dataGridView1.DataSource = (data.GetAllData()[0] as DataSet).Tables[0];
}
}
}
بعد از مدتی سروکار داشتن با مفاهیم WCF ،Web API ،WCF REST و Web Service برای تهیه یک فریم ورک قوی، به این نتیجه رسیدم که اکثر برنامه نویسان در مقایسه بین مفاهیم یاد شده به مشکل می‌خورند. در این مطلب سعی بر این است که تفاوت‌های اساسی آنها را به‌صورت کلی بیان کنم.
دانت فریم ورک با بهره‌گیری از این تکنولوژی‌ها، امکاناتی را برای ایجاد HTTP سرویس‌ها، به ما می‌دهد و قبل از بکارگیری لازم است انتخاب کنیم که از کدام تکنولوژی باید استفاده کنیم.
Web Service
1. پایه‌ی آن براساس SOAP است و داده‌ها را در قالب XML به ما می‌دهد.
2. فقط از HTTP پروتکل پشتیبانی می‌کند.
3. متن باز نیست اما می‌توان از آن در هر کلاینتی که از XML پشتیبانی می‌کند، استفاده کرد.
4. فقط بر روی IIS می‌توان آنرا هاست کرد.
WCF
1. پایه‌ی پیش فرض آن براساس SOAP است و داده‌ها را در قالب XML به ما می‌دهد.
2. تکامل یافته‌ی وب سرویس‌ها است (ASMX) و از پروتکل‌های مختلفی همچون TCP, HTTP, HTTPS, Named Pipes, MSMQ پشتیبانی می‌کند.
3. مشکل اصلی WCF در بد قلقی و گسترده بودن تنظیمات آن می‌باشد.
4. متن باز نیست، اما می‌توان از آن در هر کلاینتی که از XML پشتیبانی می‌کند، استفاده کرد.
5. بر روی IIS یا برنامه‌ها و یا ویندوز سرویس‌ها، می‌توان آنرا هاست کرد.
WCF REST
1. برای استفاده از WCF و WCF REST باید حتما webHttpBindings را فعال کرده باشید.
2. از دستور العملهای HTTP Get و HTTP POST با استفاده از ترکیب خصیصه‌های [WebGet] و [WebInvoke] ، پشتیبانی می‌کند.
3. برای فعال کردن سایر دستور العملهای HTTP باید تنظیماتی را در IIS انجام دهید، تا درخواست‌هایی که بر اساس دستورالعمل‌های ویژه‌ی در فایل svc. می‌باشند را قبول کند.
4. ارسال دیتا به آن از طریق پارامتر، با استفاده از WebGet احتیاج به تنظیماتی دارد و یا UriTemplate باید مشخص شود.
5. از XML, JSON and ATOM پشتیبانی می‌کند.
Web API
1. یک فریم ورک جدید برای ساختن HTTP سرویس، یک راه ساده و آسان.
2. متن باز است و یک راه ایده آل برای ساخت REST-ful سرویس‌ها بر روی دات نت فریم ورک.
3. برخلاف WCF Rest، سرویس‌های آن از ویژگیهای کامل HTTP مانند ( URIs, request/response headers, caching, versioning various content formats) پشتیبانی می‌کنند.
4. همچنین از ویژگیهای کامل MVC از قبیل routing, controllers, action results, filter, model binders, IOC container or dependency injection, unit testing به‌سادگی و قوی پشتیبانی می‌کند.
5. بر روی IIS و یا برنامه‌ها، می‌توان آنرا هاست کرد.
6. یک معماری سبک و مناسب برای دستگاه‌هایی که پهنای باند محدودی دارند، مانند گوشی‌های هوشمند.
7. پاسخها بوسیله Web API’s MediaTypeFormatter به صورت JSON, XML فرمت می‌شوند؛ و یا هر فرمتی را که شما می‌خواهید، به‌عنوان MediaTypeFormatter اضافه کنید .
انتخاب بین WCF یا WEB API
1.انتخاب WCF زمانی مناسب است که شما می‌خواهید یک سرویس را ایجاد کنید که باید از سناریو‌های مختلفی از قبیل پیغام‌های یکطرفه و صف پیغام‌ها و ارتباطات دو طرفه پشتیبانی کند و یا می‌خواهید یک سرویس را ایجاد کنید که از کانال‌های انتقال سریع استفاده کند؛ از قبیل TCP و Named Pipes و یا شاید گاهی UDP در WCF 4.5 و همچنین می‌خواهید از HTTP پشتیبانی کند؛ وقتی که همه‌ی کانال‌های دیگر انتقال در دسترس نیستند.
2. انتخاب Web API زمانی مناسب است که شما می‌خواهید یک resource-oriented سرویس را بر روی HTTP ایجاد کنید. در اینجا می‌توان از ویژگیهای کامل HTTP مانند URIs, request/response headers, caching, versioning, various content formats استفاده کرد و یا می‌خواهید سرویس را در معرض طیف گسترده‌ای از کلاینت‌ها شامل مرورگرها، موبایل‌ها، iphone و تبلت قرار دهید.
دانت فریم ورک با بهره‌گیری از این تکنولوژی‌ها، امکاناتی را برای ایجاد HTTP سرویس‌ها، به ما می‌دهد و قبل از بکارگیری لازم است انتخاب کنیم که از کدام تکنولوژی باید استفاده کنیم.
Web Service
1. پایه‌ی آن براساس SOAP است و داده‌ها را در قالب XML به ما می‌دهد.
2. فقط از HTTP پروتکل پشتیبانی می‌کند.
3. متن باز نیست اما می‌توان از آن در هر کلاینتی که از XML پشتیبانی می‌کند، استفاده کرد.
4. فقط بر روی IIS می‌توان آنرا هاست کرد.
WCF
1. پایه‌ی پیش فرض آن براساس SOAP است و داده‌ها را در قالب XML به ما می‌دهد.
2. تکامل یافته‌ی وب سرویس‌ها است (ASMX) و از پروتکل‌های مختلفی همچون TCP, HTTP, HTTPS, Named Pipes, MSMQ پشتیبانی می‌کند.
3. مشکل اصلی WCF در بد قلقی و گسترده بودن تنظیمات آن می‌باشد.
4. متن باز نیست، اما می‌توان از آن در هر کلاینتی که از XML پشتیبانی می‌کند، استفاده کرد.
5. بر روی IIS یا برنامه‌ها و یا ویندوز سرویس‌ها، می‌توان آنرا هاست کرد.
WCF REST
1. برای استفاده از WCF و WCF REST باید حتما webHttpBindings را فعال کرده باشید.
2. از دستور العملهای HTTP Get و HTTP POST با استفاده از ترکیب خصیصه‌های [WebGet] و [WebInvoke] ، پشتیبانی می‌کند.
3. برای فعال کردن سایر دستور العملهای HTTP باید تنظیماتی را در IIS انجام دهید، تا درخواست‌هایی که بر اساس دستورالعمل‌های ویژه‌ی در فایل svc. می‌باشند را قبول کند.
4. ارسال دیتا به آن از طریق پارامتر، با استفاده از WebGet احتیاج به تنظیماتی دارد و یا UriTemplate باید مشخص شود.
5. از XML, JSON and ATOM پشتیبانی می‌کند.
Web API
1. یک فریم ورک جدید برای ساختن HTTP سرویس، یک راه ساده و آسان.
2. متن باز است و یک راه ایده آل برای ساخت REST-ful سرویس‌ها بر روی دات نت فریم ورک.
3. برخلاف WCF Rest، سرویس‌های آن از ویژگیهای کامل HTTP مانند ( URIs, request/response headers, caching, versioning various content formats) پشتیبانی می‌کنند.
4. همچنین از ویژگیهای کامل MVC از قبیل routing, controllers, action results, filter, model binders, IOC container or dependency injection, unit testing به‌سادگی و قوی پشتیبانی می‌کند.
5. بر روی IIS و یا برنامه‌ها، می‌توان آنرا هاست کرد.
6. یک معماری سبک و مناسب برای دستگاه‌هایی که پهنای باند محدودی دارند، مانند گوشی‌های هوشمند.
7. پاسخها بوسیله Web API’s MediaTypeFormatter به صورت JSON, XML فرمت می‌شوند؛ و یا هر فرمتی را که شما می‌خواهید، به‌عنوان MediaTypeFormatter اضافه کنید .
انتخاب بین WCF یا WEB API
1.انتخاب WCF زمانی مناسب است که شما می‌خواهید یک سرویس را ایجاد کنید که باید از سناریو‌های مختلفی از قبیل پیغام‌های یکطرفه و صف پیغام‌ها و ارتباطات دو طرفه پشتیبانی کند و یا می‌خواهید یک سرویس را ایجاد کنید که از کانال‌های انتقال سریع استفاده کند؛ از قبیل TCP و Named Pipes و یا شاید گاهی UDP در WCF 4.5 و همچنین می‌خواهید از HTTP پشتیبانی کند؛ وقتی که همه‌ی کانال‌های دیگر انتقال در دسترس نیستند.
2. انتخاب Web API زمانی مناسب است که شما می‌خواهید یک resource-oriented سرویس را بر روی HTTP ایجاد کنید. در اینجا می‌توان از ویژگیهای کامل HTTP مانند URIs, request/response headers, caching, versioning, various content formats استفاده کرد و یا می‌خواهید سرویس را در معرض طیف گسترده‌ای از کلاینت‌ها شامل مرورگرها، موبایل‌ها، iphone و تبلت قرار دهید.
دقت داشته باشید که Web API عرضه نشده تا WCF رو منسوخ کنه. برنامه هایی که صرفاً از بستر پروتوکل HTTP به عنوان یک سرویس برای رد و بدل کردن داده‌ها استفاده می‌کنند، بهتره که از این به بعد از Web API استفاده کنند. ضمن سادگی و مفاهیم آشنای ASP.NET MVC، روش یکپارچه ای برای ایجاد وب سرویس‌های HTTP نیز به وجود اومده که مشکلات استفاده از WCF رو از بین می‌بره. WCF ذاتاً برای پیغام‌های SOAP محور طراحی شده و به کار گرفتن اون برای وب سرویس‌های HTTP یا به زور خوراندن HTTP به اون بی معنیه. در WCF راه‌های مختلفی برای ایجاد وب سرویس‌های HTTP وجود داره که باعث گمراهی و سردرگمی توسعه گر میشه و حتی فریمورک‌های مختلفی مانند OpenRasta و ServiceStack نیز بدین منظور وجود دارند. بنابراین پشتیبانی WCF از HTTP به یک پروژه‌ی دیگه تحت نام ASP.NET Web API منتقل شده و WCF Web API دیگه پشتیبانی نمیشه. کمی تغییر نام و کمی جابجایی مفاهیم دراینجا صورت گرفته.
WCF همچنان قدرتمنده و نباید Web API به هیچ وجه به عنوان جایگزینی برای اون تصور بشه. ایجاد بسترهایی برای ارتباطات دو طرفه یا صفی از پیغام‌ها یا سویچ بین کانال‌ها در هنگام فعال نبودن یک کانال، اینها همه از قابلیت‌هایی هست که Web API هرگز جایگزینی برای اونها نخواهد بود و مختص WCF هستند.
بخش هایی از کتاب "مرجع کامل ASP.NET MVC (با پوشش کامل ASP.NET MVC 4)"
ترجمه و تالیف: بهروز راد
وضعیت: در دست چاپ
Web API چیست؟
Web API، نوع قالب جدیدی برای پروژه‌های مبتنی بر وب در NET. است که بر مبنای اصول و الگوهای موجود در ASP.NET MVC ساخته شده است و همراه با ASP.NET MVC 4 وجود دارد. Web API توسعه گران را قادر می‌سازد تا با استفاده از یک الگوی ساده که در Controllerها پیاده سازی می‌شود، وب سرویس‌های مبتنی بر پروتوکل HTTP را با کدها و تنظیمات کم ایجاد کنند. این سبک جدید برای ایجاد وب سرویس ها، می‌تواند در انواع پروژه‌های NET. مانند ASP.NET MVC، ASP.NET Web Forms، Windows Application و ... استفاده شود.
یک سوال کاملاً منطقی در اینجا به وجود می‌آید. چرا نیاز به بستری جدید برای ایجاد وب سرویس داریم؟ آیا در حال حاضر مایکروسافت بستری محبوب و فراگیر برای توسعه‌ی وب سرویس هایی که بتوانند با پروتوکل SOAP تعامل داشته باشند در اختیار ندارد؟ مگر وب سرویس‌های ASMX از زمان معرفی ASP.NET وجود نداشته اند؟ آیا تکنولوژی WCF مایکروسافت، بیشترین انعطاف پذیری و قدرت را برای تولید وب سرویس‌ها در اختیار قرار نمی‌دهد؟ وب سرویس‌ها جایگاه خود را یافته اند و توسعه گران با تکنولوژی‌های موجود به خوبی آنها را پیاده سازی و درک می‌کنند. چرا Web API؟
چرا Web Api؟
برای پاسخ به این سوال، باید برخی مشکلات را بررسی کنیم و ببینیم ابزارهای موجود چه راه حلی برای آنها در نظر گرفته اند. اگر با گزینه هایی که در ادامه می‌آیند موافق هستید، خواندن این مطلب را ادامه دهید، و اگر اعتقادی به آنها ندارید، پس نیازهای شما به خوبی با بسترهای موجود پاسخ داده می‌شوند.
تفاوت Web API و WCF
وب سرویس‌های ASMX تا چندین سال، انتخاب اول برای ایجاد وب سرویس‌های مبتنی بر پروتوکل SOAP با استفاده از پروتوکل HTTP بودند. وب سرویس‌های ASMX، از وب سرویس‌های ساده که نیاز به قابلیت تعامل پایین داشتند و در نتیجه به پروتوکل SOAP نیز وابسته نبودند پشتیبانی نمی‌کردند. WCF جای وب سرویس‌های ASMX را گرفت و خود را به عنوان آخرین و بهترین روش برای ایجاد وب سرویس‌ها در بستر NET. معرفی کرد. نمونه ای از یک سرویس WCF بر مبنای پروتوکل HTTP در NET. به صورت ذیل است.
در WCF، پایه و اساس وب سرویس را یک interface تشکیل می‌دهد. در حقیقت اجزای وب سرویس را باید در یک interface تعریف کرد. هر یک از متدهای وب سرویس در interface تعریف شده که صفت OperationContract برای آنها در نظر گرفته شده باشد، به عنوان یکی از اَعمال و متدهای قابل فراخوانی توسط استفاده کننده از وب سرویس در دسترس هستند. سپس کلاسی باید ایجاد کرد که interface ایجاد شده را پیاده سازی می‌کند. در قسمت بعد، با مفاهیم پایه‌ی Web API و برخی کاربردهای آن در محیط ASP.NET MVC آشنا می‌شوید.
نتیجه گیری
Web API، یک روش جدید و آسان برای ایجاد وب سرویس ها، بر مبنای مفاهیم آشنای ASP.NET MVC و پایه‌ی وب است. از این روش می‌توان در انواع پروژه‌های NET. استفاده کرد.
ترجمه و تالیف: بهروز راد
وضعیت: در دست چاپ
Web API چیست؟
Web API، نوع قالب جدیدی برای پروژه‌های مبتنی بر وب در NET. است که بر مبنای اصول و الگوهای موجود در ASP.NET MVC ساخته شده است و همراه با ASP.NET MVC 4 وجود دارد. Web API توسعه گران را قادر می‌سازد تا با استفاده از یک الگوی ساده که در Controllerها پیاده سازی می‌شود، وب سرویس‌های مبتنی بر پروتوکل HTTP را با کدها و تنظیمات کم ایجاد کنند. این سبک جدید برای ایجاد وب سرویس ها، می‌تواند در انواع پروژه‌های NET. مانند ASP.NET MVC، ASP.NET Web Forms، Windows Application و ... استفاده شود.
یک سوال کاملاً منطقی در اینجا به وجود می‌آید. چرا نیاز به بستری جدید برای ایجاد وب سرویس داریم؟ آیا در حال حاضر مایکروسافت بستری محبوب و فراگیر برای توسعه‌ی وب سرویس هایی که بتوانند با پروتوکل SOAP تعامل داشته باشند در اختیار ندارد؟ مگر وب سرویس‌های ASMX از زمان معرفی ASP.NET وجود نداشته اند؟ آیا تکنولوژی WCF مایکروسافت، بیشترین انعطاف پذیری و قدرت را برای تولید وب سرویس‌ها در اختیار قرار نمی‌دهد؟ وب سرویس‌ها جایگاه خود را یافته اند و توسعه گران با تکنولوژی‌های موجود به خوبی آنها را پیاده سازی و درک می‌کنند. چرا Web API؟
چرا Web Api؟
برای پاسخ به این سوال، باید برخی مشکلات را بررسی کنیم و ببینیم ابزارهای موجود چه راه حلی برای آنها در نظر گرفته اند. اگر با گزینه هایی که در ادامه می‌آیند موافق هستید، خواندن این مطلب را ادامه دهید، و اگر اعتقادی به آنها ندارید، پس نیازهای شما به خوبی با بسترهای موجود پاسخ داده می‌شوند.
- من معتقد هستم که راه بهتری برای ایجاد وب سرویس‌ها وجود دارد.
- من معتقد هستم که روش‌های ساده‌تری برای ایجاد وب سرویس‌ها وجود دارد و WCF بیش از حد پیچیده است.
- من معتقد هستم که تکنولوژی‌های پایه‌ی وب مانند اَفعال GET، POST، PUT و DELETE برای انجام اَعمال مختلف توسط وب سرویس‌ها کافی هستند.
تفاوت Web API و WCF
وب سرویس‌های ASMX تا چندین سال، انتخاب اول برای ایجاد وب سرویس‌های مبتنی بر پروتوکل SOAP با استفاده از پروتوکل HTTP بودند. وب سرویس‌های ASMX، از وب سرویس‌های ساده که نیاز به قابلیت تعامل پایین داشتند و در نتیجه به پروتوکل SOAP نیز وابسته نبودند پشتیبانی نمی‌کردند. WCF جای وب سرویس‌های ASMX را گرفت و خود را به عنوان آخرین و بهترین روش برای ایجاد وب سرویس‌ها در بستر NET. معرفی کرد. نمونه ای از یک سرویس WCF بر مبنای پروتوکل HTTP در NET. به صورت ذیل است.
[ServiceContract]
public interface IService1
{
[OperationContract]
string GetData(int value);
[OperationContract]
CompositeType GetDataUsingDataContract(CompositeType composite);
}
...
public class Service1 : IService1
{
public string GetData(int value)
{
return string.Format("You entered: {0}", value);
}
public CompositeType GetDataUsingDataContract(CompositeType composite)
{
if (composite == null)
{
throw new ArgumentNullException("composite");
}
if (composite.BoolValue)
{
composite.StringValue += "Suffix";
}
return composite;
}
}
نتیجه گیری
Web API، یک روش جدید و آسان برای ایجاد وب سرویس ها، بر مبنای مفاهیم آشنای ASP.NET MVC و پایه‌ی وب است. از این روش می‌توان در انواع پروژه‌های NET. استفاده کرد.
الف) تنظیمات سرور
برای اضافه کردن تنظیمات WCF، ابتدا فایل mod_mono.conf را باز کنید:
بعد در سطر اول آن پسوند svc را هم اضافه کنید:
و همچنین اینکار را برای فایل default آپاچی انجام دهید:
و پسوند svc را در اینجا نیز اضافه نمائید:
بعد از آن یکبار سرور را با دستور sudo service apache2 restart ری استارت کنید.
ب) تنظیمات وب کانفیگ
در اینجا serviceMetadata را طوری تنظیم کنید تا با HTTP GET قابل دریافت باشد
بعد از آن سرویس شما در آدرس http://127.0.0.1/webforms_test/Service1.svc/js یا در آدرس http://127.0.0.1/webforms_test/Service1.svc/jsdebug برای کارهای Ajax ایی قابل استفاده خواهد بود (فرض بر این بود که یک Ajax Enabled WCF Service را در VS.NET ایجاد و به لینوکس منتقل کردید).
برای اضافه کردن تنظیمات WCF، ابتدا فایل mod_mono.conf را باز کنید:
sudo gedit /etc/apache2/mods-available/mod_mono.conf
AddType application/x-asp-net .svc .aspx .ashx .asmx .ascx .asax .config .ascx
sudo gedit /etc/apache2/sites-available/default
AddHandler mono .svc .aspx .ascx .asax .ashx .config .cs .asmx .axd
ب) تنظیمات وب کانفیگ
در اینجا serviceMetadata را طوری تنظیم کنید تا با HTTP GET قابل دریافت باشد
<system.serviceModel>
<behaviors>
<serviceBehaviors>
<behavior>
<serviceMetadata httpGetEnabled="true" httpGetUrl="wsdl"/>
</behavior>
</serviceBehaviors> 
در پست قبلی توضیحات کلی درباره WCF Routing Service داده شد و یک مثال را نیز با هم بررسی کردیم. همان طور که در مثال مشاهده شد با استفاده از تعاریف فیلتر در جدول فیلترها توانستیم درخواست‌های مورد نظر را به مقاصد مربوطه اتصال دهیم. در این پست نگاه عمیق‌تری به FilterTable خواهیم داشت.
MessageFilter ها:
با استفاده از این نوع، می‌توان فیلتر مورد نظر را بر روی Message گسترش داد. برای مثال ارزیابی نام فرستنده Message یا حتی نوع عملیات Soap. حتی می‌توانیم فیلترها را با استفاده از And با هم ترکیب نماییم.
FilterType ها
این enum دارای مقادیر زیر است:
Filter Table
در واقع مجموعه ای است از اشیای تعریف شده از نوع FilterTableEntryElement که ارتباط را بین یک فیلتر و مقصد (Endpoint) تعیین می‌نماید. هم چنین امکان تعریف اولویت برای هرکدام از مقصد‌ها یا Endpointها وجود دارد.
یک مثال:
می‌توان برای فیلترها اولویت تعیین کرد. این کار از طریق تنظیم خاصیت Priority امکان پذیر است. در صورت عدم تعیین Prioirty مقدار پیش فرض صفر خواهد بود.
در مثال بالا برای یک endpointName مشترک دو فیلتر نوشته شده است با اولویت‌های متفاوت. دو صورتی که اولویت‌ها یکسان باشد با توجه به ترتیب تعریف در filterTable، فیلترها اعمال خواهند شد.
تهیه BackupList
BackupListها این امکانی را در اختیار ما قرار خواهند داد که بتوانیم در صورت عدم موفقیت در عملیات مسیر یابی (برای مثال وقوع CommunicationException) لیستی از مسیر‌های جایگزین را تعیین نماییم. در صورت وقوع هر گونه خطا در هنگام فراخوانی سرویس، به جای مواجه شدن با یک استثنا، عملیات مسیر یابی به صورت خودکار به endpointهای تعیین شده در BackupList منتقل خواهد شد.
در مثال بالا دو endpoint در لیست backup قرار دارد. در صورت وقوع استثنا در Destination عملیات ابتدا به backupServiceQueue منتقل می‌شود و اگر باز هم خطایی وجود داشت نوبت به alternateServiceQueue خواهد رسید.
MessageFilter ها:
با استفاده از این نوع، می‌توان فیلتر مورد نظر را بر روی Message گسترش داد. برای مثال ارزیابی نام فرستنده Message یا حتی نوع عملیات Soap. حتی می‌توانیم فیلترها را با استفاده از And با هم ترکیب نماییم.
FilterType ها
این enum دارای مقادیر زیر است:
- Action : با استفاده ActionMessageFilter فیلتر مورد نظر انجام می‌شود.
- And : با استفاده از StrictAndMessageFilter دو فیلتر مورد نظر را با هم ترکیب می‌کند.
- Custom : می‌توان فیلتر مورد نظر را تعریف کرده و این جا فراخوانی نمایید.
- MatchAll : با استفاده از MatchAllMessageFilter تمام فیلترها بررسی خواهند شد.
- EndpointAddress : برای فیلتر ادرس درخواست‌های با استفاده از EndpointAddressMessageFilter مورد استفاده قرار می‌گیرد.
- EndpointName : فیلتر با استفاده EndpointNameMessageFilter بر روی نام Endpoint سرویس مورد نظر انجام می‌گیرد.
FilterData برای تعیین مقادیر مورد نیاز برای FilterType مورد استفاده قرار می‌گیرد.
برای مثال:
<filters>
<filter name="EndpointNameFilter" filterType="EndpointName"
filterData="calculatorEndpoint"/>
<filter name="RoundRobinFilter1" filterType="Custom"
customType="RoutingServiceFilters.RoundRobinMessageFilter,
RoutingService" filterData="group1"/>
<filter name="RoundRobinFilter2" filterType="Custom"
customType="RoutingServiceFilters.RoundRobinMessageFilter,
RoutingService" filterData="group1"/>
</filters> در واقع مجموعه ای است از اشیای تعریف شده از نوع FilterTableEntryElement که ارتباط را بین یک فیلتر و مقصد (Endpoint) تعیین می‌نماید. هم چنین امکان تعریف اولویت برای هرکدام از مقصد‌ها یا Endpointها وجود دارد.
یک مثال:
<routing>
<filters>
<filter name="AddAction" filterType="Action" filterData=”Add” />
<filter name="SubtractAction" filterType="Action" filterData=”Subtract” />
</filters>
<filterTables>
<table name="routingTable1">
<filters>
<add filterName="AddAction" endpointName="Addition" />
<add filterName="SubtractAction" endpointName="Subtraction" />
</filters>
</table>
</filterTables>
</routing> می‌توان برای فیلترها اولویت تعیین کرد. این کار از طریق تنظیم خاصیت Priority امکان پذیر است. در صورت عدم تعیین Prioirty مقدار پیش فرض صفر خواهد بود.
<filterTables>
<filterTable name="filterTable1">
<add filterName="EndpointNameFilter" endpointName="regularCalcEndpoint"
priority="1"/>
<add filterName="MatchAllMessageFilter" endpointName="defaultCalcEndpoint"
priority="0"/>
</filterTable>
</filterTables> تهیه BackupList
BackupListها این امکانی را در اختیار ما قرار خواهند داد که بتوانیم در صورت عدم موفقیت در عملیات مسیر یابی (برای مثال وقوع CommunicationException) لیستی از مسیر‌های جایگزین را تعیین نماییم. در صورت وقوع هر گونه خطا در هنگام فراخوانی سرویس، به جای مواجه شدن با یک استثنا، عملیات مسیر یابی به صورت خودکار به endpointهای تعیین شده در BackupList منتقل خواهد شد.
<filterTables>
<filterTable name="filterTable1">
<add filterName="MatchAllFilter1" endpointName="Destination" backupList="backupEndpointList"/>
</filterTable>
</filterTables>
<backupLists>
<backupList name="backupEndpointList">
<add endpointName="backupServiceQueue" />
<add endpointName="alternateServiceQueue" />
</backupList>
</backupLists>