با آمدن Asp.Net Web API کار ساختن Web APIها برای برنامه نویس‌ها به خصوص دسته ای که با ساخت API و
وب سرویس آشنا نبودند خیلی ساده‌تر شد . اگر با Asp.Net MVC آشنا باشید
خیلی سریع می‌توانید اولین Web Service خودتان را بسازید .
در صفحه مربوط به Asp.Net Web API آمده است که این فریمورک بستر مناسبی برای ساخت و توسعه برنامه های RESTful است . اما تنها ساختن کنترلر و اکشن و برگشت دادن داده‌ها به سمت کلاینت ، به خودی خود برنامه شما رو تبدیل به یک RESTful API نمی‌کند .
مثل تمام مفاهیم و ابزارها ، طراحی و ساختن RESTful API هم دارای اصول و Best Practice هایی است که رعایت آنها به خصوص در این زمینه از اهمیت زیادی برخوردار است . همانطور که از تعریف API برمی آید شما در حال طراحی رابطی هستید تا به توسعه دهندگان دیگر امکان دهید از داده‌ها و یا خدمات شما در برنامه‌ها و سرویس هایشان استفاده کنند . مانند APIهای توئیتر و نقشه گوگل که برنامه‌های زیادی بر مبنای آنها ساخته شده اند . در واقع توسعه دهندگان مشتریان API شما هستند .
بهره وری توسعه دهنده مهمترین اصل
اینطور می‌توان نتیجه گرفت که اولین و
مهمترین اصل در طراحی API باید رضایت و موفقیت توسعه دهنده در درک و
یادگیری سریع API شما ،نه تنها با کمترین زحمت بلکه همراه با حس نشاط ، باشد. ( تجربه کاربری در اینجا هم می‌تواند صدق کند ). سعی کنید در زمان
انتخاب از بین روش‌های طراحی موجود ، از دیدگاه توسعه دهنده به مسئله نگاه کنید .
خود را به جای او قرار دهید و تصور کنید که می‌خواهید با استفاده از API
موجود یک رابط کاربری طراحی کنید یا یک اپلیکشن برای موبایل بنویسید و اصل را این
نکته قرار دهید که بهره وری برنامه نویس را حداکثر کنید. ممکن است گاهی بین طرحی که بر اساس این اصل برای API خود در نظر داریم و یکی از اصول یا استانداردها تعارض بوجود بیاید . در این موارد بعد از اینکه مطمئن شدیم این اختلاف ناشی از طراحی و درک اشتباه خودمان نیست (که اکثرا هست ) ارجحیت را باید به طراحی بدهیم .
{
"dependencies": {
"Microsoft.NETCore.App": {
"version": "1.0.0",
"type": "platform"
},
"Microsoft.AspNetCore.Diagnostics": "1.0.0",
"Microsoft.AspNetCore.Server.IISIntegration": "1.0.0",
"Microsoft.AspNetCore.Server.Kestrel": "1.0.0",
"Microsoft.Extensions.Logging.Console": "1.0.0"
}, using Microsoft.AspNetCore.Builder;
using Microsoft.AspNetCore.Http;
using Microsoft.Extensions.DependencyInjection;
namespace Core1RtmEmptyTest
{
public class Startup
{
public void ConfigureServices(IServiceCollection services)
{
}
public void Configure(IApplicationBuilder app)
{
app.UseWelcomePage();
app.Run(async (context) =>
{
await context.Response.WriteAsync("Hello DNT!");
});
}
}
} 
bower install chosen
{
"name": "asp-net-mvc5x-angular2x",
"version": "1.0.0",
"authors": [
"DNT"
],
"license": "MIT",
"ignore": [
"node_modules",
"bower_components"
],
"dependencies": {
"chosen": "1.4.2"
},
"devDependencies": {
}
} <script src="~/node_modules/jquery/dist/jquery.min.js"></script> <script src="~/node_modules/bootstrap/dist/js/bootstrap.min.js"></script> <script src="~/bower_components/chosen/chosen.jquery.min.js"></script> <link href="~/bower_components/chosen/chosen.min.css" rel="stylesheet" type="text/css" />
declare var jQuery: any;
constructor(private _el: ElementRef) {
} import { Component, ElementRef, AfterViewInit } from "@angular/core";
declare var jQuery: any; // untyped
@Component({
templateUrl: "app/using-jquery-addons/using-jquery-addons.component.html"
})
export class UsingJQueryAddonsComponent implements AfterViewInit {
dropDownItems = ["First", "Second", "Third"];
selectedValue = "Second";
constructor(private _el: ElementRef) {
}
ngAfterViewInit() {
jQuery(this._el.nativeElement)
.find("select")
.chosen()
.on("change", (e, args) => {
this.selectedValue = args.selected;
});
}
} <select>
<option *ngFor="let item of dropDownItems"
[value]="item"
[selected]="item == selectedValue">
{{item}} option
</option>
</select>
<h4> {{selectedValue}}</h4> 
npm install -g typings typings install jquery --save --ambient
/// <reference path="../typings/browser/ambient/jquery/index.d.ts" />
// declare var jQuery: any; // untyped declare var jQuery: JQueryStatic; // typed
interface JQuery {
//...
chosen(options?:any):JQuery;
}
declare module "jquery" {
export = $;
} 
Start > Control Panel -> Appearance and Personalization -> Fonts -> Font Settings -> Restore Default Font Settings
public static string Right(this string s, int length)
{
length = Math.Max(length, 0);
if (s.Length > length)
{
return s.Substring(s.Length - length, length);
}
else
{
return s;
}
}
string s = "abcde";
s = s.Right(3); //s becomes "cde"
آغاز فصل سوم:
در فصل گذشته در مورد بسته بندی و توزیع اسمبلی‌ها، بررسی‌هایی را انجام دادیم. در این نوع توزیع، فرض ما بر این بود که دسترسی به اسمبلی‌ها، از طریق دایرکتوری خود اپلیکیشن می‌باشد؛ ولی برای اسمبلی‌های عمومی، صحبتی به میان نیاوردیم. در این فصل، ما تمرکز خود را برای توزیع اسمبلی‌های عمومی می‌گذاریم. اسمبلی‌های عمومی این قابلیت را می‌دهند که از طریق چند اپلیکیشن قابل دسترسی باشند. ساده‌ترین و قابل دسترس‌ترین نمونه‌ی این اسمبلی‌ها، اسمبلی‌های خود دات نت فریم ورک هستند؛ یا نمونه‌ی دیگر، شرکت‌های ثالثی مثل تلریک، که برای استفاده‌ی دیگر برنامه نویسان اسمبلی می‌سازند.
مشکلی که در توزیع اسمبلی‌های عمومی وجود دارد این است که شما باید این اطمینان را کسب کنید که اسمبلی شما، همیشه همان اسمبلی خواهد بود و تغییری در آن رخ نخواهد داد. فرض کنید که شما از یک اسمبلی که توسط شرکت تلریک تهیه شده است استفاده کرده‌اید و برنامه‌ی شما به خوبی با آن کار می‌کند. ولی چه اتفاقی می‌افتد که اگر برنامه‌ی دیگری بعد از شما نصب شود و از همان اسمبلی، منتها از نسخه‌ی دیگر آن استفاده می‌کند؟ بله برنامه‌ی شما احتمال زیادی دارد که در این حالت به مشکل بر بخورد یا اینکه شخص دیگری یک اسمبلی دیگری همنام اسمبلی و هم نسخه‌ی اسمبلی شما تولید می‌کند. برای رفع این مشکلات مایکروسافت تمهیداتی را اندیشیده است که ما به آن می‌گوییم «اسمبلی با نام قوی Strong Name Assembly».
اسمبلی‌ها به دو دسته تقسیم می‌شوند: اسمبلی‌های با نام قوی و اسمبلی
هایی با نام ضعیف ( این مورد در مستندات مایکروسافت نیست و توسط نویسنده‌ی کتاب، این
اصطلاح ایجاد شده است).
در قسمت دوم گفتیم که اسمبلی‌ها از قسمت‌هایی چون جداول مانیفست، هدرها، متادیتاها و ... تشکیل می‌شوند. اسمبلی‌های نام قوی هم به همین شکل هستند. فقط توسط جفت کلید عمومی و خصوصی محافظت و امضا می‌شوند که برای ناشر، یک کلید منحصر به فرد را ایجاد می‌کنند و به ناشر این اطمینان را می‌دهند که اگر جفت کلیدی را که در دست شما است، به کسی ندهید، هیچ کس دیگری نمی‌تواند اسمبلی را با مشخصات اسمبلی شما امضاء کند.
حال یک اسمبلی نام قوی، دارای چهار خصوصیت است: نام اسمبلی بدون پسوند، نگارش، فرهنگ (Culture) و کلید عمومی.
از آنجا که خود کلید عمومی بسیار بزرگ می‌باشد، ما برای استفاده‌ی راحت‌تر، از توکن کلید عمومی استفاده می‌کنیم که طول کمتری دارد. توکن کلید عمومی، یک مقدار هش شده است که از کلید عمومی به دست می‌آید:
"MyTypes, Version=1.0.8123.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" "MyTypes, Version=1.0.8123.0, Culture="enUS", PublicKeyToken=b77a5c561934e089" "MyTypes, Version=2.0.1234.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" "MyTypes, Version=1.0.8123.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
استفاده از فضای نام
System.Reflection.AssemblyName
به شما اجازه‌ی ساخت و دریافت اطلاعاتی را از اسمبلی‌ها می‌دهد؛ هر نوع اطلاعاتی را که شامل 4 خصوصیت بالا می‌شود، به شما می‌دهد.
از آنجا که مطالب مربوطه به امضاء کردن اسمبلی، در سایت جاری موجود می‌باشند، این مباحث را می‌توانید از طریق این مقاله "نام قوی" دنبال کنید تا در این باره گزافه گویی نکرده باشیم .
تصویر زیر توضیح بند بالا را نشان می‌دهد:
مختصری در مورد GAC
%SystemRoot%\Microsoft.NET\Assembly
/reference:System.Drawing.dll
PM> Install-Package Microsoft.Owin.Host.SystemWeb PM> Install-Package Microsoft.Owin.Security.Jwt PM> Install-Package structuremap PM> Install-Package structuremap.web
<appJwtConfiguration
tokenPath="/login"
expirationMinutes="2"
refreshTokenExpirationMinutes="60"
jwtKey="This is my shared key, not so secret, secret!"
jwtIssuer="http://localhost/"
jwtAudience="Any" /> <configSections>
<section name="appJwtConfiguration" type="JwtWithWebAPI.JsonWebTokenConfig.AppJwtConfiguration" />
</configSections> public interface ITokenStoreService
{
void CreateUserToken(UserToken userToken);
bool IsValidToken(string accessToken, int userId);
void DeleteExpiredTokens();
UserToken FindToken(string refreshTokenIdHash);
void DeleteToken(string refreshTokenIdHash);
void InvalidateUserTokens(int userId);
void UpdateUserToken(int userId, string accessTokenHash);
} public void CreateUserToken(UserToken userToken)
{
InvalidateUserTokens(userToken.OwnerUserId);
_tokens.Add(userToken);
} public interface IUsersService
{
string GetSerialNumber(int userId);
IEnumerable<string> GetUserRoles(int userId);
User FindUser(string username, string password);
User FindUser(int userId);
void UpdateUserLastActivityDate(int userId);
} public interface ISecurityService
{
string GetSha256Hash(string input);
} function doLogin() {
$.ajax({
url: "/login", // web.config --> appConfiguration -> tokenPath
data: {
username: "Vahid",
password: "1234",
grant_type: "password"
},
type: 'POST', // POST `form encoded` data
contentType: 'application/x-www-form-urlencoded' identity.AddClaim(new Claim(ClaimTypes.UserData, user.UserId.ToString()));
function doRefreshToken() {
// obtaining new tokens using the refresh_token should happen only if the id_token has expired.
// it is a bad practice to call the endpoint to get a new token every time you do an API call.
$.ajax({
url: "/login", // web.config --> appConfiguration -> tokenPath
data: {
grant_type: "refresh_token",
refresh_token: refreshToken
},
type: 'POST', // POST `form encoded` data
contentType: 'application/x-www-form-urlencoded' [JwtAuthorize(Roles = "Admin")] public class MyProtectedAdminApiController : ApiController
var jwtToken;
var refreshToken;
function doLogin() {
$.ajax({
// same as before
}).then(function (response) {
jwtToken = response.access_token;
refreshToken = response.refresh_token;
} function doCallApi() {
$.ajax({
headers: { 'Authorization': 'Bearer ' + jwtToken },
url: "/api/MyProtectedApi",
type: 'GET'
}).then(function (response) { function doLogout() {
$.ajax({
headers: { 'Authorization': 'Bearer ' + jwtToken },
url: "/api/user/logout",
type: 'GET' public AppOAuthProvider( Func<IUsersService> usersService, Func<ITokenStoreService> tokenStoreService, ISecurityService securityService, IAppJwtConfiguration configuration)