① 易語言怎樣用api實現伺服器、客戶組建的功能
可以搜索下Socket套接字，一般的流程是：
WSAStartup 初始化Socket庫
socket 創建Socket實例 ，也就是這步確定是UDP還是TCP,是客戶還是伺服器
然後伺服器則是bind綁定埠，listen監聽埠,recv接收數據,sned發送數據
客戶則是connect連接客戶端，接收和發送和伺服器一樣
數據報則是bind綁定，recvfrom接收數據，sendto發送數據
當然最後還需要closeSocket關閉套接字實例和WSACleanup釋放套接字型檔
我這里這是簡單的提一下流程，具體的要參看專門講Socket的教程！
② 內網伺服器如何調用第三方的API
能訪問外網的伺服器上搭建一個http透明代理只允許內網訪問，內網CURL指定proxy就可以了。或者可以使用SSH的埠轉發功能實現。
假定A是本地內網主機，B是遠程提供第三方服務的主機，這兩台主機之間無法連通。但是，現在還有一台C，可以同時連通前面兩台主機。因此，很自然的想法就是，通過C，將A連上B。
③ 怎麼把自己的主機做成伺服器
最近工作需要IIS，自己的電腦又是系統之家win7純凈版系統，找了下安裝的方法，已經安裝成功。在博客里記錄一下，給需要的朋友，也是給自己留個備份，畢竟我腦子不是很好使。
一、首先是安裝IIS。打開控制面板，找到「程序與功能」，點進去
二、點擊左側「打開或關閉Windows功能」
三、找到「Internet 信息服務」，按照下圖打勾即可
等待安裝完成
四、安裝完成後，再回到控制面板裡面，找到「管理工具」，點進入
五、雙擊「Internet 信息服務(IIS)管理器」就是IIS了。如果經常需要使用IIS的朋友，建議滑鼠指到「Internet 信息服務(IIS)管理器」上，右鍵--發送到--桌面快捷方式，這樣就能從桌面進入IIS，而不用每次都點控制面板。
IIS界面：
六、選中「Default Web Site」，雙擊中間的「ASP」
把「啟用父路徑」改為「True」
七、下面就是配置站點了。單擊右側「高級設置」
選擇你網站的目錄
八、回到IIS，單擊右側的「綁定...」，選中你要綁定的網站，點「編輯」
如果是一台電腦，只修改後面的埠號就行，可以隨意修改數字。如果是辦公室區域網，點擊下拉框，選擇自己電腦上的區域網IP，例如：192.168.**.**，然後修改埠號
九、回到IIS，如果右側顯示停止，就選擇啟動，然後點擊下面的瀏覽網站，就可以打開你綁定文件夾裡面的網站了
十、如果有多個網站，在IIS左邊「網站」右鍵「添加網站」
主要修改三個地方，「網站名稱」、「物理路徑」、「埠」，如果區域網，請修改「IP地址」，同上
十一、添加好後，點擊新建的網站名字，就是這個網站的詳情了。
本來這次是打算用Discuz!NT來做的，方便與以後做的asp.net網站對接會員。但是老闆要求快速，而Discuz!NT我連放到本地VS 裡面運行都忘記了，所以只好用Discuz! 7.2來做算了。關於主題我也只能下載一個類似的主題然後修改顏色，因為自己也沒接觸過製作論壇主題。
歡迎轉載，本文標題：IIS的安裝和配置
轉載請註明原文網址：http://zz.dsidc.cn/html/huanjing/IIS/2014/0101/4278.html
④ 如何在伺服器上使用jmessage的rest api
不一樣 WS 有WS的客戶端調用 REST 就是簡單的HTTP請求，還可以瀏覽器直接調用 基於REST FUL的介面性能相比WS 好多了 WS的體系現在很完整，REST是沒興起多久的方式，不過後面REST會占很大份額 樓主，沒疑問就採納了吧
⑤ 用C++如何實現開放API介面伺服器
c++的話，一般用libevent或則libev這種庫來實現吧。當然如果對epoll比較熟悉的話直接用也沒問題。也可直接用直接用Nginx或Apache+PHP/java/Ruby。
⑥ java 伺服器做app api介面怎麼做比較好
日常開發主要使用XML或者JSON做數據交換
XML（Extensible Markup Language，簡稱：XML），是一種標記語言，用來傳送及攜帶數據信息。
JSON(JavaScript Object Notation) 是一種輕量級的數據交換格式。同XML或HTML片段相比，JSON提供了更好的簡單性和靈活性，
JSON的數據格式：
1）並列數據之間以逗號（,）分隔；
2）映射用冒號（:）表示；
3）並列數據的集合用方括弧（[]）表示；
4）映射的集合用大括弧（{}）表示。
⑦ api伺服器怎麼架設
因為 API 的設計本身最關鍵的難題並不是讓客戶端與服務端軟體之間如何交互，而是設計者、維護者、API使用者這幾個程序員群體之間在 API 生命周期內的互動。一個 API 如何被使用，以及API本身如何被維護，是依賴於維護者和使用者能夠對該 API 有清晰的、一致的認識。這非常依賴於設計者提供了一個清晰易於理解的模型。這種狀況實際上是不容易達到的。
⑧ websocket伺服器端能不能用api代替
WebSocket的出現是基於Web應用的實時性需要而產生的。這種實時的Web應用大家應該不陌生，在生活中都應該用到過，比如新浪微博的評論、私信的通知，騰訊的WebQQ等。讓我們來回顧下實時 Web 應用的窘境吧。
在WebSocket出現之前，一般通過兩種方式來實現Web實時用：輪詢機制和流技術；其中輪詢有不同的輪詢，還有一種叫Comet的長輪詢。
輪詢：這是最早的一種實現實時 Web 應用的方案。客戶端以一定的時間間隔向服務端發出請求，以頻繁請求的方式來保持客戶端和伺服器端的同步。這種同步方案的缺點是，當客戶端以固定頻率向服務 器發起請求的時候，伺服器端的數據可能並沒有更新，這樣會帶來很多無謂的網路傳輸，所以這是一種非常低效的實時方案。
長輪詢：是對定時輪詢的改進和提高，目地是為了降低無效的網路傳輸。當伺服器端沒有數據更新的時候，連接會保持一段時間周期直到數據或狀態改變或者 時間過期，通過這種機制來減少無效的客戶端和伺服器間的交互。當然，如果服務端的數據變更非常頻繁的話，這種機制和定時輪詢比較起來沒有本質上的性能的提 高。
流：常就是在客戶端的頁面使用一個隱藏的窗口向服務端發出一個長連接的請求。伺服器端接到這個請求後作出回應並不斷更新連接狀態以保證客戶端和服務 器端的連接不過期。通過這種機制可以將伺服器端的信息源源不斷地推向客戶端。這種機制在用戶體驗上有一點問題，需要針對不同的瀏覽器設計不同的方案來改進 用戶體驗，同時這種機制在並發比較大的情況下，對伺服器端的資源是一個極大的考驗。
上述方式其實並不是真正的實時技術，只是使用了一種技巧來實現的模擬實時。在每次客戶端和伺服器端交互的時候都是一次 HTTP 的請求和應答的過程，而每一次的 HTTP 請求和應答都帶有完整的 HTTP 頭信息，這就增加了每次傳輸的數據量。但這些方式最痛苦的是開發人員，因為不論客戶端還是伺服器端的實現都很復雜，為了模擬比較真實的實時效果，開發人員 往往需要構造兩個HTTP連接來模擬客戶端和伺服器之間的雙向通訊，一個連接用來處理客戶端到伺服器端的數據傳輸，一個連接用來處理伺服器端到客戶端的數 據傳輸，這不可避免地增加了編程實現的復雜度，也增加了伺服器端的負載，制約了應用系統的擴展性。
基於上述弊端，實現Web實時應用的技術出現了，WebSocket通過瀏覽器提供的API真正實現了具備像C/S架構下的桌面系統的實時通訊能 力。其原理是使用JavaScript調用瀏覽器的API發出一個WebSocket請求至伺服器，經過一次握手，和伺服器建立了TCP通訊，因為它本質 上是一個TCP連接，所以數據傳輸的穩定性強和數據傳輸量比較小。
WebSocket 協議
WebSocket 協議本質上是一個基於 TCP 的協議。為了建立一個 WebSocket 連接，客戶端瀏覽器首先要向伺服器發起一個 HTTP 請求，這個請求和通常的 HTTP 請求不同，包含了一些附加頭信息，其中附加頭信息」Upgrade: WebSocket」表明這是一個申請協議升級的 HTTP 請求，伺服器端解析這些附加的頭信息然後產生應答信息返回給客戶端，客戶端和伺服器端的 WebSocket 連接就建立起來了，雙方就可以通過這個連接通道自由的傳遞信息，並且這個連接會持續存在直到客戶端或者伺服器端的某一方主動的關閉連接。
下面我們來詳細介紹一下 WebSocket 協議，由於這個協議目前還是處於草案階段，版本的變化比較快，我們選擇目前最新的 draft-ietf-hybi-thewebsocketprotocol-17 版本來描述 WebSocket 協議。因為這個版本目前在一些主流的瀏覽器上比如 Chrome,、FireFox、Opera 上都得到比較好的支持。通過描述可以看到握手協議
客戶端發到伺服器的內容:
代碼如下 復制代碼
GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin:
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13
從伺服器到客戶端的內容:
代碼如下 復制代碼
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Protocol: chat
這些請求和通常的 HTTP 請求很相似，但是其中有些內容是和 WebSocket 協議密切相關的。我們需要簡單介紹一下這些請求和應答信息，」Upgrade:WebSocket」表示這是一個特殊的 HTTP 請求，請求的目的就是要將客戶端和伺服器端的通訊協議從 HTTP 協議升級到 WebSocket 協議。其中客戶端的Sec-WebSocket-Key和伺服器端的Sec-WebSocket-Accept就是重要的握手認證信息了，這些內容將在服 務器端實現的博文中講解。
相信通過上文的講解你應該對WebSocket有了個初步認識了，如果有任何疑問歡迎交流。
客戶端
如概念篇中介紹的握手協議，客戶端是由瀏覽器提供了API，所以只要使用JavaScript來簡單調用即可，而伺服器端是要自己實現的，伺服器端將在下個博文來講。
代碼如下 復制代碼
WebSocket JavaScript 介面定義:
[Constructor(in DOMString url, optional in DOMString protocol)]
interface WebSocket {
readonly attribute DOMString URL;
// ready state
const unsigned short CONNECTING = 0;
const unsigned short OPEN = 1;
const unsigned short CLOSED = 2;
readonly attribute unsigned short readyState;
readonly attribute unsigned long bufferedAmount;
// networking
attribute Function onopen;
attribute Function onmessage;
attribute Function onclose;
boolean send(in DOMString data);
void close();
};
WebSocket implements EventTarget;
簡單了解下介面方法和屬性：
readyState表示連接有四種狀態：
CONNECTING (0)：表示還沒建立連接；
OPEN (1)： 已經建立連接，可以進行通訊；
CLOSING (2)：通過關閉握手，正在關閉連接；
CLOSED (3)：連接已經關閉或無法打開；
url是代表 WebSocket 伺服器的網路地址，協議通常是」ws」或「wss(加密通信)」,send 方法就是發送數據到伺服器端；
close 方法就是關閉連接；
onopen連接建立，即握手成功觸發的事件；
onmessage收到伺服器消息時觸發的事件；
onerror異常觸發的事件；
onclose關閉連接觸發的事件；
JavaScript調用瀏覽器介面實例如下：
代碼如下 復制代碼
var wsServer = 'ws://localhost:8888/Demo'; //伺服器地址
var websocket = new WebSocket(wsServer); //創建WebSocket對象
websocket.send("hello");//向伺服器發送消息
alert(websocket.readyState);//查看websocket當前狀態
websocket.onopen = function (evt) {
//已經建立連接
};
websocket.onclose = function (evt) {
//已經關閉連接
};
websocket.onmessage = function (evt) {
//收到伺服器消息，使用evt.data提取
};
websocket.onerror = function (evt) {
//產生異常
};
⑨ 阿里雲伺服器ecs怎麼創建api介面
購買雲盤後到控制台進行掛載，掛載到目標伺服器上。掛載成功後目標伺服器會出現新的磁碟（未格式化、未分區）這時候進入伺服器格式化、分區該磁碟、創建邏輯分區即可使用。注意下Win系統和Linux系統的掛載方法
⑩ 內部系統可以做成通過REST API的方式調用嗎
想要為開發工程師們開發一個既能滿足REST約束條件和原則又不像OAuth OAuth 那樣復雜 the complexity ，僅僅使用簡單的傳值語句或者其它簡單但同樣安全的方法就能實現的web API?
聰明人會有聰明的想法…
問題
直接通過HTTP literally passing the credentials over HTTP以文本方式傳輸鑒權信息可能會被破譯; 尤其在 Gawker incident, 再以文本或是弱加密的方式傳輸鑒權信息是非常不安全的做法 weakly-hashed anything is usually a bad idea.
即便是使用哈希加密後還是很有可能被人根據彩虹表 Rainbow Table破譯出與用戶名匹配的密碼（個別案例）
這可該怎麼辦，真是郁悶…
也許你又會想到很多公共的API popular public APIs在請求中採用雙數據的模式：一個公有值一個（最好是有）只有屬主能訪問的私有值。
」還是有點不對!」這不跟原來（用戶名密碼模式）文本模式差不多麼，還是可能會被（嗅探器）破譯。
這時候你可能准備放棄並採用OAuth模式了，但仍堅信必有某種簡單方法能實現公用webAPI安全訪問私有鑒權信息。
解決方案
連續2天的Peyote實驗後（你可能會找到更好的放鬆辦法），結論終於呈現在你眼前：Amazon是擁有最大的、使用最多的在線網路API的網路服務之一，並且根本不支持OAuth！
經過一個下午長時間的狂想之後，你最終敗下陣來，並看到Amazon是如何保持API請求安全的。你不清楚為什麼，但讀完整頁關於如何為Amazon網路服務裝配一個請求後，你依然覺得不完全合理。這個「簽名」和什麼連在一起？代碼示例中的「data」參數是什麼？這樣，你會繼續查找關於「安全API設計」的文章。。。
當遇到其他人問同樣的問題時，你看到一些指出"HMAC"或其他事物的優秀回復，但還是不太確定。
你找到其他鼓勵你使用「HMAC」的文章並且你正H-FINE地使用它，如果有人將「HMAC」解釋成簡明的H_ENGLISH的話。
你的確偶遇了一個有道理的蒸餾的基本概念，它是這樣一簡明的英語描述的：
一個伺服器和客戶端知道一個公鑰和一個私鑰；只有伺服器和客戶端知道私鑰，但每個人都知道公鑰。。。但不關心別人所知道的。
一個客戶端生成一個唯一的HMAC（哈希）表示它到伺服器的請求。通過把請求數據（參數和值或XML/JSON或任何它計劃發送的數據）以及請求數據的散列blob和私鑰結合來實現。
客戶端隨後將這個HASH以及所有它將要發送的參數和值一並發給伺服器。
伺服器接到請求，並使用與客戶端相同的方式重新生成自己獨有的基於提交值的HMAC（哈希）。
然後，伺服器比較這兩個HMAC，如果相同，伺服器就信任這個客戶端並執行請求。
這似乎很直截了當。最初讓你困惑的是，你以為原始請求是經過加密傳送的，但實際上，HMAC方法所做的一切只是使用只有客戶端和伺服器才知道的私鑰將參數生成為一些獨特的校驗和（哈希）。
隨後，客戶端將這個校驗和及原始參數和值發給伺服器，然後伺服器復核校驗和（哈希）以確定它接受客戶端所發的請求。
因為根據假設，只有在客戶端和伺服器知道私鑰，我們假設如果他們的哈希匹配，那麼它們會互相信任，以至伺服器隨即正常處理這個請求。
你知道在現實中，這就相當於某人過來對你說：「Jimmy讓我告訴你把錢給Johnny」，但你不知道這個人是誰，所以你要伸出手去試探他，看看他是否知道這個秘密握手。
如果三次握手證明無誤，則通訊繼續進行，否則中斷通訊。.
你明白了大概是怎麼回事，但還是想會不會還有更好的方法呢？還好，有tarsnap網站 tarsnap幫你答疑解惑。看看亞馬遜是如何解決簽名認證問題的Amazon screwed this up with Signature Version 1.
看完了亞馬遜的web service是如何鑒權的，re-read how Amazon Web Services does authentication 講的確實有道理，整個流程如下:
[客戶端]在調用REST API之前，首先將待發送消息體打包, combine a bunch of unique data together(websevice端將要接收的數據)
[客戶端]用系統分派的密鑰使用哈希(最好是HMAC-SHA1 or SHA256 ) 加密(第一步的數據).
[客戶端]向伺服器發送數據:
用戶身份認證信息例如,用戶ID，客戶ID或是其他能別用戶身份的信息。這是公共API，大家都能訪問的到(自然也包括了那些居心叵測的訪問者)系統僅僅需要這部分信息來區分發信人而不考慮可靠與否(當然可以通過HMAC來判斷可靠性).
發送生成的HMAC碼.
發送消息體（屬性名和屬性值），如果是私有信息需要加密，像是（「mode=start&number=4&order=desc」或其他不重要的信息）直接發送即可.
(可選項)避免重放攻擊 「replay attacks」 o的唯一辦法就是加上時間戳。在使用HMAC演算法時加入時間戳，這樣系統就能依據一定的條件去驗證是否有重放的請求並拒絕.
[伺服器端]接收客戶端發來的消息.
[伺服器端] (參看可選項)檢查接收時間和發送時間的間隔是否在允許范圍內（5-15分）以避免重放攻擊replay attacks.
提示: 確保待檢對象的時區無誤daylight savings time
更新: 最近得到的結論就是直接使用UTC時區而無需考慮DST的問題 use UTC time .
[伺服器端]使用發送請求中用戶信息（比如.API值）從資料庫檢索出對應的私匙.
[伺服器端] 跟客戶端相同，先將消息體打包然後用剛得到的私匙加密（生成HMAC）消息體.
(參看可選項) 如果你使用了加入時間戳的方式避免重放攻擊，請確保服務端生成的加密信息中擁有和客戶端相同的時間戳信息以避免中間人攻擊man-in-the-middle attack.
[伺服器端] 就像在客戶端一樣，使用HMAC哈希加密剛才的信息體.
[伺服器端] 將伺服器端剛生成的哈希與客戶端的對比。如果一致，則通訊繼續；否則，拒絕請求!
提示: 在打包消息體的時候一定要考慮清楚，如果像亞馬遜進行簽名版本1中信息識別那樣會面臨哈希沖突的問題 open yourself up to hash-collisions! (建議：將整個包含URL的請求加密即可!)
特別提示:私匙絕對不能在通訊過程中傳遞，它僅僅用來生成HMAC,伺服器端會自動查詢出它的私匙並重新生成自己的HMAC.我來翻譯公匙僅僅用來區分不同的用戶，即使被破解也無所謂。因為此時的消息無需判斷其可靠性，服務端和客戶端還是要通過私匙來加密（比如，前綴、後綴，倍數等等）
10/13/11更新：Chris最近發現 pointed out 如果在HMAC計算中加入了URI或是HTTP請求/回復，攻擊者更易通過更改末端或是HTTP方法來搞破壞。比如，在HTTP POST方法中將/issue/create改成/user/delete。