只有一个按键的 bt.tn 的互联网连接器,有什么亮点?

-

The bttn - the simplest user interface in the world

虽然说能连接互联网上各种api,但是再怎么用也就一个按钮。
而且售价高达$69... 实在看不出来有什么应用范围。
看了网站的介绍视频也没看懂。.

我猜人家的意思是,你可以在家里放满几万个这种button,顺便用标签贴上功能,然后就可以在家里创建自己的控制面板了,多么有复古的味道啊。

API 智能家居 iffttt 硬件创业

网站后台要做客户端API接口,接口文档如何写?

-

有一个网站外包项目,需求方是我这边提的需求, 现在网站项目要做客户端app的接口数据,就是提供给app的API, 外包公司问我需要提供多少API, 要求我提供一份需要的API接口规范文档;

我刚刚接触产品经理,不太懂这个;请问这个流程有没有问题;还有主要的问题是这个接口文档如何写? 有没有格式参考? 请给我一个参考的案例;感激不尽

谢谢各位@
I am G.gladman

我们所接触的项目,接口文档一般是API提供方提供的,所以只能作为提供方来回答了,希望对你有帮助。
下面是自己以前制作的一份接口文档的主要框架,仅供参考:
文档信息
文档名称
文档管理编号
保密级别
文档类型
扩散范围
适用范围
版权所有
版本变更记录
版本 说明 时间 修改人
1.0 新建文档 2013-12-1 6某某某

目录

1. 接口定义
接口 说明
接口1 接口1说明
1.1接口1定义
接口调用请求说明
http请求方式:POST/FORM
编码方式:UTF-8
xxxxx
示例(使用curl命令):
curl -F resultFile=@/tmp/xxx -k xxx
参数说明
参数 说明
参数1 参数1说明
返回值
正确情况下的返回:


0 // 返回码,返回码详细定义参见附录
// 返回码描述信息

......


错误情况下的返回:


1 // 返回码,返回码详细定义参见附录
// 返回码描述信息


2. 附录
2.1 返回码详细定义
返回码 描述
0 请求成功
1 缺少用户名或密码
2 用户名或密码错误

产品经理 API Android 应用 网站 网站后台

代码耦合是怎么回事呢?

-

耦合,谁之错?业务耦合,架构耦合,代码耦合,依次产生,前者是后者的催化剂,最终结果是系统严重耦合,无法适应任何变化。
这其中,业务耦合是根本,必须从根防治与修正,否则没有用,只会越来越差,最终崩塌。
当然,耦合也要从业务、架构、代码三个层面抓起,在每个层面减少耦合,为后面减少耦合打好基础。

以前,我写代码时,我考虑模块(本文中的模块就是指单个源文件)的单向依赖关系,考虑接口的正交性和紧凑性。
我觉得我在做低耦合的好设计。

然而,我发现其他程序员写的代码依赖关系混乱,接口臃肿,但他们仍然觉得自己写的代码耦合很低,设计很好。
我这才发现,我理解的耦合和他们理解的不一样。
他们理解的低耦合就是把代码提出来,让代码不要“乱”。
然而,对于什么是“耦合”、什么是“乱”,他们并不知道有什么客观标准可以度量。

所以,现在我相信“耦合”是个有歧义的坏词,“低耦合”是个程序员经常误用的理论。
我建议,设计架构、考察模块之间关系时,不要用“耦合”、“乱”这些无法度量的词语,而应该改用以下三个可以度量的指标:依赖、正交性、紧凑性。

依赖和耦合的最大区别在于,当我们说“A和B耦合”时,在字面含义中,A和B二者平等。
然而,正确的模块关系根本不应该平等,而应该是单向依赖才对。
所以我们应该说“A依赖B”,这样含义要清楚得多。
A依赖B意味着,A模块可以调用B模块暴露的API,但B模块绝不允许调用A模块的API。
单向依赖是红线,好的设计一定不会违反这条红线。

注意:根据实质重于形式原则,本文中的“依赖”指人脑中的依赖而不是编译器的依赖。
只要程序员编写模块A时,需要知道模块B的存在,需要知道模块B提供哪些功能,A对B依赖就存在。
甚至就算通过所谓的依赖注入、命名查找之类的“解耦”手段,让模块A不需要import B或者include "B.h",人脑中的依赖仍旧一点都没有变化。
唯一的作用是会骗过后文会提到的代码打分工具,让工具误以为两个模块间没有依赖。

所以 @翟志军 的例子中的解耦只是在自娱自乐兜圈子而已。
因为不管你用什么技术手段,Configuration的调用方程序员总是需要知道配置项的具体业务含义才能用啊。

很多程序员觉得“耦合”是坏事,爱写兜圈子的代码来消除所谓的“耦合”。
但是我们改用“依赖”术语后,我们就发现单向依赖不是坏事,根本不必费心消除,
因为,真正的重点是,依赖关系中,被依赖方暴露的接口能不能足够“正交”和“紧凑”。

正交性是指一个模块提供的API中,多个方法之间是否有重复的功能。
如果有重复功能,正交性就差。
通常,正交性高的模块更稳定,不会因为上层业务变化而被迫修改代码。
好的API内部的多个方法之间不应该有任何重复功能,只实现正交的机制。

如果感觉拆得太细使用不便,应该在底层API之外包装出一层Helper、Utility组成的胶水层。
胶水层调用底层原语API来实现常用模式供上层使用。
对于胶水层中的模块,对正交性的要求可以稍低一些。
注意上层代码既可以直接调用正交的底层API,又可以调用胶水层的常用模式。

紧凑性是指一个模块提供的API中,公有方法总数必须很少,每个方法的参数也必须很少。
《Unix编程艺术》上说一个模块不要超过7个方法,不然就很难理解。
但我实践中发现,我一般编写的模块,公有方法通常不超过3个。

总之,单向依赖、正交性、紧凑性这三个指标都很务实,有客观方法可以度量。
我觉得也许可以代替“低耦合”这种“公说公有理婆说婆有理”的务虚理论。
比如前两天我们ThoughtWorks的咨询师邮件列表中就有人分享一些工具,用上述标准自动检查代码质量。
那么将来你和别的程序员约架,你要喷对方代码写得烂,你就有了依据,因为你可以直接用工具给代码打分。

另外,将来如果有同事或者网友在讨论编程时,用了“耦合”、“解耦”、“乱”之类的混乱术语,你可以把这篇文章发给他看,然后鄙视他。

API 软件架构 设计模式 编程范式 接口设计

从零到搭建一个能提供API接口的网站,过程是怎样的?

-

想要搭建一个服务器,24小时运行一个程序抓取诸如天气、汇率之类的东西,然后提供API接口(以xml或json的形式)给手机端调用。

请问要做到以上大概的步骤是怎样的,有没有什么教程推荐?
目前会objective-c语言,服务器端需要学什么语言呢,python如何?

最简单的api,事实上比一般的单页程序还稍简单一些,因为不用考虑输出的html。直接输出json或xml。
无非是做个url,比如xx.jsp, xx.php等,获取参数,输出结果,只是结果输出不用html格式,而是用json,或xml格式。

Python API 编程 服务器 网站运营

设计RPC框架时,客户端调用出错是直接抛出异常好,还是返回errcode好?

-

我的理解:
errcode简单性能好,多语言支持方便,但是code很多的时候,客户端需要分别处理,容易遗漏,问题可能会被埋藏起来发现不了。

exception对客户端更友好,代码可以少写很多if ... else ... 有预期外的错误可以及时发现。

大家怎么看这个问题?跨语言的情形和不跨语言是否有不同?

反正在协议里面你只有返回error和error附带的所有信息,然后针对不同的语言可以有不同的做法,譬如说C语言你只能error然后写一个GetRPCError函数读详细内容,C++和C#你就可以封装成不同的exception类,Haskell直接就写成CoMonad了,etc

Web 开发 API 编程 远程过程调用协议RPC(Remote Procedure Call Protocol)

能否比较一下常见C++开发框架的API风格?

-

比如Qt、VCL、MFC、Win32……不行说说Android/IOS也行。

看到一篇文章,有感而发
设计Qt风格的C++API

马一个晚上给你写 2015年8月17日15:00:00
————————————————————————————————
OK 首先我纠正一下楼主的问题,Win32其实不是什么C++开发框架,不过我明白题主想说的是Win32 SDK,所谓Win32 SDK其实就是用于windows平台开发的一整套API集合,这套API集合囊括了用于windows平台上面的各个模块编程的接口(函数),然而这套API集合并不是按照C++调用方式导出的,而是标准的C式函数导出的。因为Windows的整个内核部分都是用C语言完成的,并且上层的Win32子系统部分也是完全的C语言,所以对外提供的编程接口都是C式调用(试想如果对外提供C++的编程接口,那么就相当于无法使用C语言为这个系统开发软件,对早期Windows来说简直是失掉80%的应用软件。当然诞生先后也有关系,没记错的话1985年第一个C++发布,1985年windows 1.0已经发布了)

其次,题主想问常见的C++开发框架,但是提问中却点出了MFC,我觉得题主应该把平台相关库和跨平台的库区分开来,MFC作为Windows平台的特定开发框架,并不应该算作是常见的C++开发框架,同样的ATL,WTL等都不能算作常见的C++开发框架,MFC,ATL,WTL这些native框架以及.NET,WPF等这些managed框架,以及始于Windows 8,现在又在Windows 10 release的WinRt框架(这个C++,C#,Javascript通吃的)这些都是针对特定Windows 平台的开发框架,你说常见可能也常见,但是并不会被业界强烈要求必须掌握。

关于类库框架,卖个瓜先:从汇编语言到类库框架的随感

而常见的C++开发框架,我觉得应该是:STL,Qt,Boost,VCL(笔者只在Delphi上用过,所以不做介绍了),这些框架都是支持跨平台的,其中这里面又可以细分一下:
QT作为一个完整的应用程序开发框架,他涵盖了从GUI到各种基础库(IO,网络等等)的所有功能。
而STL和Boost,他们都是不提供GUI开发的基础功能库,其中STL提供的功能相比Boost更少。

我举个简单的例子,如果你要用这些框架写一个运行在windows系统上的程序,这个程序有个窗口,有个按钮,你点击按钮就会发送一个UDP包到任意IP,这个程序首先进行UI和业务逻辑分解:

1)一个带按钮的窗口UI
2)通过Socket发送UDP报文。你现在的选择有若干种。

1.纯的Win32 SDK(C语言或者C++均可):UI和业务都用Win32 SDK socket
2.MFC(C++):UI和业务都用MFC提供的封装类库
3.MFC+Win32 SDK:UI用Win32 SDK,业务用MFC或者对换
4.Win32 SDK + Boost:UI用Win32 SDK,业务用Boost的网络类库
5.纯Qt:UI和业务全部用Qt的封装类库
6.Qt + Boost:UI用Qt,业务用Boost
7.Qt + Win32 SDK:UI用QT,业务用Win32 SDK或者对换
当然还有MFC+Qt,MFC+Boost,不过我觉得就算是中国TOP3的架构师这么用也会被喷死的把

OK,扯了这么多,我现在一一点一下各个框架的,我也只是初入茅庐,力所能及点到为止,如有不妥之处还望大牛不吝赐教。

Win32 SDK(基本剑术):
其实上面说的那些个组合,如果目标平台一单确定为Windows,那么他们最终都是被编译器编译成了调用Win32 SDK的API的程序,所以Win32 SDK是一切能够在其上运行的框架的根基,所谓跨平台框架就是,这个框架的实现代码里面大量的使用#ifdefine xxxxxx 这样的宏来判断当前编译的目标平台,如过是Windows就调用Windows上的完成对应功能的API,如果是Linux就调用Linux上的对应功能的函数了(这里仅限C++跨平台,托管代码JAVA,.NET这种是另外一回事)。这就是Win32 SDK,关于Win32 SDK的更详细的深层剖析,可以看看笔者的另外一篇老文章:
Windows系统调用架构分析
这篇文章主要顺便讲了一下API和syscall的概念的区别,对于一般有需求从底层学习的人来说,如果想在Windows系统上发展,Win32 SDK是必不可少的学习过程,这个是能帮你解决一切Windows 问题的根本。

MFC(攻杀剑术):
其实这货在一个Windows开发者的修炼过程中,只有阶段性的作用,对以后向更高境界的发展有一定程度(仅仅是一定程度)的帮助。MFC这个框架里面有不少值得学习的设计思想,比如撇开语言提供给的RTTI(当时C++不支持RTTI),消息映射,Command路由等等,GUI方面用框架的类对象封装Win32 SDK的native对象。其中MFC中最最频繁的一个思想就是各种“表(table)驱动”(这个也可以说是整个windows系统中的一个被用烂的思想,各种表驱动)。
至于为什么只是有一定程度的帮助,因为自始至终MFC广为诟病的一个缺点就是“臃肿不堪”,确实是这样的,MFC的几个共享库对于一个商业软件来说真的太大了,假如QQ里面用了MFC(之前确实是用了)安装包可能要大保守估计四五M,对单个用户来说没有任何问题,但是对于TX来说,那个流量就有点影响某些数据的美观程度了。
所以,MFC适合快速开发一些自用的或者确实不在乎分发的副本大小的软件程序,一般企业做一些内部支撑还是可以搞搞的(我有个朋友叫套哥,大牛,他跟我吐槽过国内某个最大的视屏聊天公司,后台大部分代码都是用MFC写的……估计只有TOP3的架构师才能发现这样做的优势!)。但是我们是有更高追求的人,所以了解了解,能熟练的用MFC开发一些中小型软件就行了,简历上就可以写:能熟练使用没饭吃进行软件开发,就OK了,不要留恋,赶紧学下一个技能。

ATL,WTL(刺杀剑术):
上面说到MFC的缺点,MFC的臃肿的缺点暴露是伴随着COM(请注意:COM只是一种!!思想!!并是不说一提到COM就一定想到他是微软专门为Windows搞得一套极复杂又过时的框架,微软提出了COM的模型,然后顺便在自己的系统上做出了一个实现版本而已,遵循COM思想可以在任何平台系统自己实现一套COM体系,而且COM确实是在二进制级别实现可重用的极其先进的思想)的发展而日益凸显的,起初没有ATL,微软就给MFC增加了COM和OLE的一些特性,简化了COM的开发,但是发现用MFC开发的COM组件在网络传输中消耗了太多资源,所以决定重新搞一个轻量高效的新框架,所以ATL诞生了。ATL和MFC有一部分代码是共享的,都是一些公共基础功能的类库,比如CString,CRect,CPoint等等。ALT相比MFC的提升就是使用了多继承和模板,这一点对GUI程序的性能提升尤为明显,ATL通过多继承把窗口的属性,方法和事件处理分离开来。其中比较有代表性的实现是继承一个实现自身的模板的说起来有点拗口:
class CHelloWnd :
public CWindowImpl {}
这样可以到达不用虚函数,而直接在编译期间生成直接的方法调用,自己体会体会。
还有一个就是thunk技术的使用,其实就是一个跳板,主要解决把WndProc成员方法化,这个要展开说又是一篇长论文,就不展开了。
ATL是目前来说开发windows程序的最高效精简的框架了。然后WTL,WTL是微软的一个员工自己写的,微软目前也还没有把这一套模板库纳入官方,WTL就是在ATL的基础上对Windows的大部分控件进行了更加有力的封装,而且方法函数中全部都是直接调用Win32 SDK,有了WTL再来开发windows GUI程序真的是前所未有的方便,所以其实MFC已经可以彻底退休了。

容我睡个觉明天继续 2015年8月18日00:10:05
————————————————————————————————
接....
昨天码了这大半篇回头才发现题主就是问一下API风格,我先在这里补充一下:
Win32 SDK 是散装API,可以按照功能模块划分为若干个大类,具体的分组方法可以看这里:
Windows API Index (Windows) 。对于具体的API来说,虽然是C语言,但是仍然离不开“面向对象”的思想,由于C语言本身不提供OO的语言特性,所以OO的实现只能是在系统中去实现。因此很多API的第一个参数都需要提供一个操作对象,这个对象可能是窗口,内核对象句柄,Socket等等,因为是C语言封装API,所以这些API操作的对象都的具体数据内容都是交由Windows系统去分配和管理的(表驱动,窗口句柄婊,内核对象句柄婊,ATOM婊等等婊),而开发者只需要调用API告诉系统,给我造个风筝(比如一个button控件),然后把风筝线(句柄handle)给我,然后开发者拿着这个风筝线,继续通过各种API去控制和设置这个风筝的各种属性(大小,位置,文字等等)。
HWND mainWnd = CreateWindow();
SetWindowText(mainWnd, _T("xxx"));
SetWindowPos(mainWnd, ...);
GetWindowRect(mainWnd, &rc);
DestroyWindow(mainWnd)
这就是典型的Win32 SDK的API风格,因为是C语言,所以遇到需要传输复杂类型的数据的时候,只有一种选择,那就是指针,因为没有引用这种东西,这就增加内存泄漏的可能性。另外几乎所有的涉及到字符串的API,都有两个实现:UNICODE版本和ANSI版本,比如
SetWindowText,其实这不是一个API的名字,只是一个宏,而真正的API名字是
SetWindowTextW,UNICODE版本
SetWindowTextA,ANSI版本
而在开发过程中如果定义了UNICODE(或者UNICODE_)的预处理宏,那么你写在代码里面的所有SetWindowText都会在编译期间被宏展开为SetWindowTextW。

而到了MFC,ATL,WTL,已经都使用C++写的了,所以就直接把风筝线封装在类中,然后给类加一堆属性,方法,在调用这些属性,方法的时候,内部直接就操作本对实例中的风筝线。

题主发的那篇文章:设计 Qt 风格的C++ API,我觉得作者是特别推崇Qt,不过Qt相比MFC这种古董一样的东西确实有很多优点:
首先,Qt的成员函数明确的划分了属性(properties),方法(methods),信号,槽函数,这只不过是OO编程中的基本思想,对象应该具有:属性,方法,更高一层的有事件,代理。C++是静态语言,所以Qt搞了个Meta object compiler,然后悄悄地在你写代码的同时给你的类插入了一些支持元编程以及RTTI的额外代码。
在这里对以下.Net和Qt:
1)首先在成员函数的类别划分上,基本没有谁好谁坏之说,但是因为C#语言上支持propertie,而C++只能用函数来模拟propertie,所以Qt在这方面可以说有先天缺陷。
2)其次API参数问题,.NET是C#属于托管,一个引用打遍天下什么都不用程序员去考虑,但是Qt是C++,有指针有引用还有直接对象传参,不同的传参类型影响安全是一方面,另一方更重要的是对执行效率的影响,一个Vector如果所有API都是用对象传参,堆栈深度10几层,每个stack frame都去拷贝一次,时间,空间全部牺牲了。
3)再者,Qt的信号其实相当于C#中的event关键字实现的功能,Qt的槽相当于C#的event handler,所不同的是C#语言原生支持delegate,拿到一个event 加加加加加一串handler,相当于Qt中用同一个对象的同一个signal connect了N个对象的slot。Qt是在运行时维护一个Connection列表。而这一切的本质,其实就是我先声明一个特定签名的函数,你要是想让我通知你,那你就按照这个签名写个函数,然后把函数指针给我,我会调用你。
上次记得看到一个提问C++语言缺少对象级别的消息传递,看到姚老师回答了Qt的Signal/Slot机制,我还是要说,Qt的SS机制已经是在语言级别之上完成的一个功能,跟C++没有可比性,一个是框架,一个是语言,这真心不能说明Qt是多么牛逼的框架(实际上我认为Qt里面很多令人感觉EW的东西,半成品,至少目前没有完成)。

说到这里,题主应该明白:
Qt,Boost,STL同属一类,Boost的signal也是可耐科特来可耐科特去的
.NET, Android那一套属于一类。

2015年8月19日00:04:51
完结
————————————————————————————————
QT(半月弯刀):
Boost,STL(烈火剑法):

开发框架 API 编程 Qt(C++框架) C++

NPAPI 为什么会被 Chrome 禁用?受影响的网站有什么普遍性?

-

相关问题:

其实何止是Chrome, 几乎所有的浏览器厂商都在淘汰/去掉NPAPI的支持


Opera: 我早就说了啊
火狐 :我还是会支持的,只是大家要一起来淘汰这个技术.

如果我告诉你 Flash 也是NPAPI插件,你会不会是这个样子

那么 NPAPI 到底出了什么问题?

NPAPI全称叫 Netscape plugin API, 你没有看错,就是那个当年被微软一棒子打死了好多年的 Netscape。

很久以前, Netscape 发明了NPAPI 这个种架构,来帮助浏览器渲染一些HTML没有的东西。比如 PDF, 比如 视频, 以及等等。。

事实上, NPAPI 插件架构是个非常好的架构, 一共就40几个API, 相对于另外一种浏览器插件架构: ActiveX来说,简直就是业界良心。

这里只有一个问题,它的发明时间是 1995 年,而在那个时候手机还可以砸死人,学校的电脑房要穿鞋套才能进。

那个时代所有类似的API设计者几乎都很自然的忽略掉了安全性问题。那个时候无论是网络环境还是商业环境相比现在都简单很多。

我们来看看NPAPI插件和浏览器的关系是什么, 同时对比下和同样执行网络下载代码的 Javascript 引擎的位置,


看懂了吧, 你以为是NPAPI是插件是吗?其实它和浏览器是平级运行的,它甚至可以打开网页,给你安一个木马,然后随手帮你关掉杀毒软件。什么,你说NPAPI不就40几个API嘛, 少年,你想多了,NPAPI不限制插件自由访问系统所有的API.

而 Javascript 引擎的限制就多得多,事实上,Chromium 系列的浏览器 Javascript 引擎均是运行在沙盒之中,一举一动都是被严密监视着的,敢有异常? 浏览器分分钟杀死你。

除了安全性以外,插件们还质量参差不齐,一旦崩溃浏览器就得跟着一起崩掉。 于是各个浏览器又一把鼻涕一遍泪的把插件们放到另外一个进程中运行,惹不起你们我们还躲不起嘛。其他的耗电量,图形效率,脚本效率一类的我就不多讲了,讲多了都是泪。

不过如果只是安全,那你把插件放到沙箱里面隔离起来不就行了嘛。

是的,谷歌当年也是这样想的,于是他们发明了 PPAPI, 然后在业界里面振臂一呼,大家来看,我的这个新API好啊,插件用起来更安全,有沙箱哦。

这个是业界伙伴们的态度:

Java: 我最近听说Chrome不支持我们了,大家请换浏览器,就这样

火狐: 我们对 PPAPI(pepper) 一点兴趣都木有。
(而且坑爹的是, Google 的PPAPI链接居然指的是Mozilla 的这个页面。不知道是不是存心恶心Mozilla).

如果你是个程序猿又有一颗好奇的心,表示无法理解PPAPI为何如此不受待见,你可以去这里看看PPAPI的文档 ,在这里
code.google.com/p/ppapi

你一定会发现问题,其实不管你是不是程序猿你都会发现问题。因为,这个PPAPI官方文档链接里面,几乎木有文档。。

不过Adobe认怂了。 事实上Adobe很早就开始发布PPAI的版本。


所以如果你这几天再看到插件无法运行的对话框,如果上面写的是Flash, 你只需要去下载一个最新的ppai的flash 插件,或者下载一个新版的Chrome. 因为目前Chrome已经开始内置PPAPI版的Flash。

其他的,就看厂商们如何跟进吧。

========================================================================

总结来讲:
NPAPI 会被禁掉, 不过PPAPI会被继续支持,于是:
  • Java Plugin 需要重写
  • UnityPlugin 需要重写
  • SliverLight Plugin 需要重写。
用到以上插件的网站会收到影响。
使用 Flash 插件的网站不会收到影响, 因为 Flash 已经重写了。。

下面是 Google 对 流行NPAPI 的统计数据:

所以,普遍性就是:
如果你还在用任何一款NPAPI插件,然后对应的插件还没有PPAI版本或者HTML 替代版的话。9月以后节哀顺变吧。。

Google Chrome API 网站 信息安全 谷歌 (Google)

截图为什么会有相机快门开关一样的过程?

-

在电脑桌面,手机桌面和程序、游戏截图,屏幕上会有一个短暂的相机快门一样的刷新过程,而有些游戏却不会如3D游戏!

真正相机快门并不是那样的动作,而是上下两个帘幕做先后运动,低速快门有一个完全张开的时间,而高速快门则是帘幕之间一条缝隙划过。能够维持一个完全张开状态的最高速快门每台相机都不一样,称为这台相机的闪光灯同步速度(其实这些跟LZ的问题关系不大啦)

Slow motion camera shutter - Canon 5D Mark II http://my.tv.sohu.com/us/49163152/14807669.shtml

API 图形图像 系统科学

谷歌字体被墙,有什么好的解决方法。如果自己已有字体,要如何搭建?求详细

-

这个问题分两方面:

1. 对于访问网站时发现字体刷不出来的受害者而言,可以选择使用 gooreplacer 等插件。

2. 对于从事开发工作的受害者而言,可以选择一些镜像服务。USTC LUG 维护了一个,我之前用在生产环境下,也没什么问题。

此外,USTC LUG 还做了很多类似的值得尊重的工作。

字体 API

交通违章查询的网站提供API接口吗?

-

上海的违章查询网站地址:shjtaq.com/zwfg/dzjc_ne
其他城市也有类似的网站。
请问这些网站提供API接口地址吗?
想做违章查询应用,请问哪里有稳定的API接口?
接口的最终数据应该最好以交通局为准。

扯蛋,测试对比了几家的违章查询。微车、司机帮、聚合、车易行,haoservice。就haoservice最垃圾,表面上支持,实际屁都查询不出来,其余的几家都还可以,毕竟全国那么多城市,接口不可能永久100%稳定的。

API 违章 车辆违章

大家有了解Twilio的吗?

-

Twilio 是位于美国加州的一家科技公司,Twilio的程序接口支持网络开发者把拨打和接听电话

1、Twilio是什么?
Twilio是一个专注通讯服务的开放PaaS平台、是一个提供技术能力的网站,也是美国较为知名的云计算通讯服务类的初创企业。

Twilio通过将复杂的底层通信功能打包成 API 并对外开放,让 web、桌面及移动应用可以方便地嵌入短信、语音及 VoIP 功能,从而实现云通信的功能。

2、Twilio的业务模式是怎样的?

短信类服务
举例来说明 Twilio 的作用。比方说你开发了一项服务,该服务每天会向用户发送一条与自己宠物有关的短信(短信仍然是最有效最普及的渠道)。但是考虑到这些用户从属于不同的运营商,所以要想实现这一点你需要针对不同运营商的短信网关做接口,因此这件事情仍然非常麻烦。但是通过 Twilio 几行代码就可以搞定。

VoIP语音通话类服务
举例来说,如果商务社交网站LinkedIn想要加入新功能,让用户可以与其他用户进行网络语音通话。那么,在Twilio Client的帮助下,LinkedIn可以轻易加入该功能:点击某个好友的网名旁的一个按钮,对方就可以看到弹出窗口,询问是否愿意接通,通话将通过 Twilio公司的网络电话线路进行。Skype或许也可以提供此类服务,但恐怕只会向特别合作伙伴提供,而Twilio的新功能是任何应用都可以采用 的。

3、Twilio在资本市场表现
6月初,媒体报道:Twilio在 D 轮融资中获得 7000 万美元,这是 Twilio 的第四轮融资,由 Redpoint Ventures 和原投资者 Bessemer Venture Partners 领投。此前 Twilio 的融资额已达 3350 万美元,此轮融资后其总融资已达 1.035 亿美元,资金应该已经足够,因此该公司下一步的资本动作有可能就是 IPO 了。

4、中国本土化“Twilio”——云通讯平台
在国外,类似云通讯的服务并不是个新鲜名词,Twilio、Plivo、Nexmo等创业公司都为开发者提供类似的服务。在中国也有本土化云通讯服务类开放平台——云通讯平台,云通讯平台是国内第一家为互联网开发者提供基于电信网络和 IP 方式的通讯技术解决方案和网络服务。
云通讯平台目前发布的API能力集包括:网络通话、IM、语音对讲、语音会议、视频通话、视频会议等。

硅谷创业公司 API Twilio 云通讯平台 网络电话平台

编程前后端怎么配合的?

-

比方说app怎么和后端开接口的人配合的
前端怎么和php配合?
合mast是什么意思?
接口具体是什么东西?
我理解的ios开发做个外壳,后端往里填充数据这想法对吗?
数据表是个什么意思?
他们编写的程序都存在哪?
能用外行人听得懂的语言给我们形象的比喻一下扫盲吗?

web环境下,前端是跟客户面对面的部分,后端则是与数据库、业务逻辑连一起的部分。把App算做前端也没错,但是具体到职业上目前前端更多的还是html、css、js的舞台。

某种意义上确实是做个壳,因为前端部分很透明,分分钟就被别人抄走,所以一般不会去扣具体业务逻辑。但这个壳其实包含对用户的界面逻辑和计算校验数据之类的工作不少都要前端做。

具体合作基本上是做好API文档,约定好怎么交互,后端需要的数据和前端需要的接口都用文字提供出来。最好是采用某些固定模式,比如RESTful,然后就能各做各的互不干涉了。

API 编程 自学编程 Codecademy 后台开发

向下兼容真的是破坏程序、API「美感」的元凶吗?

-

向下兼容有三种做法,第一种是不需要人们在使用新功能的时候修改代码的,譬如说普通的Windows API。第二种是需要人们在使用新功能的时候修改代码的,譬如说DirectX。第三种介于他们之间,仅在同一个流程里需要使用新功能的时候修改这局部的代码,譬如Windows的locale api。


为什么api会变化?这都源自于需求的变化。一开始的变化可能只是添加一些新功能(譬如DX8到DX9)。当你的需求的变化大到连抽象的概念都要一起变的时候(譬如DX9到DX10),你就必须大刀阔斧的改了。因此这个时候,保持API美感的最好的方法就是——做个全新的接口,然后不要删掉旧的,对旧的除了修bug什么也不要做。


因此向下兼容并不一定会破坏美感。只要你从一开始的设计针对当时的需求就是完美地,那添加一些小需求也是不会破坏美感的。当概念发生了重大变化,接口就必须全部翻新,只要不阻止人们继续用旧的就好了,这是他们的自由。破坏美感的是一味的追求【完美的向下兼容】,或者更傻逼的【向上兼容】。

产品设计 软件 程序员 API 编程

同时在两个账号中,发送相同微博,这样的设定可以实现吗?

-

假如有这样一个软件,被两个微博账号授权,可以帮助这两个账号同时发送一条相同的微博。这样的软件在技术上可以实现吗?(或者是已经有了)
网上搜索到有“ access_token”就可以,不太明白。(新浪微博API 微博开发文档)
同理,在人人平台里,能够实现发状吗?
在QQ平台可以发状态吗?

可以实现。

微博 API iOS 开发 开放 API 人人网 API

请问,知乎能否有手机版?或者,你的页面排版不要总是变换代码。

-

用手机浏览知乎不容易,于是做了一个利用PHP CURL做了简单的知乎手机版。
但是,知乎总是不领情,昨天把对应知乎更新,修改了对应的正则过滤,今天用手机浏览,才发现知乎又把代码改了。

知乎要么开放API,要么自己出手机版。这样,我就算喜欢知乎也无法在其他地方浏览了。

知乎的页面有为移动终端优化,用Android/IOS自带的浏览器就有很好效果,不要用ucweb之类。

由于我们使用的google closure框架,编译模版时会把class,id里面的名称替换掉,所以无法依据这个来做正则的。
是的,我们正开发api中。手机版Native客户端也不远了。
update: 现在能对ucweb有更好的识别了,除了访问识别移动设备自动转换为移动版外,也可以直接通过m.zhihu.com访问移动版了。

知乎 API 知乎移动网页版

基于NodeJS Restify的Restfull API是否适合做中间层?

-

针对目前项目,应用服务的控制层(Web、Wap和APP API三部分)共用业务层和数据层,近期考虑把业务层和数据层分离出去替换为无状态的Restfull API,这样应用服务专心负责权限验证、页面渲染、缓存策略、国际化等问题,也不必担心应用服务的语言选择或迁移问题(目前是Python),是否可行以及有无前辈踩过的坑,请指教~

适合

API Node.js 性能 中间件 解决方案

如何通过python调用新浪微博的API来爬取数据 ?

-

研究课题需要爬取一部分新浪微博的数据来做实验 但是苦与找不到合适的手段 听说通过新浪微博的API可以过去到数据 初步研究了一下 遇到了好多的问题 首先appkey就不知道如何申请 另外 如果想较高的掌握这个技术 需要系统的学习什么内容

新浪的api基本上你都可以调用,官网上有各个语言的sdk。只要你申请一个应用,系统就会发给你appkey和appsecret,用你的微博账号就可以申请。我用的是python3,不过官网上是2的sdk,你只要掌握了一门编程语言,基本上一个星期就可以调用了。网上有分享的各种经验,依葫芦画瓢,只要调用了一个api,基本上所有的都会了。前提是,你必须要熟练的掌握一门编程语言。

API 爬虫(计算机网络) 新浪微博 API

RESTful API的命名有什么讲究?

-

比如以上3个API (RESTful API 设计指南
1. 这个URL和服务器里的文件夹有关系么?是否网站根目录下需要有v1这个文件夹?
2. GET /zoos/ID 和 GET ID/zoos 两种实现在效果上有区别么? 推荐前者的原因是什么?
谢谢!

和目录没关系,通常是框架路由接管的 request uri解析出来的(v1、v2有可能是实际的目录)

restful规范
/资源名/id/资源名/id
以上为从属关系
/zoos
zoos资源的索引

/zoos/15
zoos资源里的第15个资源

/zoos/15/animals
zoos资源里的第15个资源里的animals资源的索引

/zoos/15/animals/150
代表zoos资源里第15个资源里的的animals资源的底150个

http同框架的关系可以参考以下

Rails 路由全解
Ruby on Rails 實戰聖經

数据库 API 后端技术 编程 RESTful

如何设计API接口,请求接口时需要进行身份验证,防止第三方随意调用接口?

-

接口是放在公网中使用,不想随意被第三方使用。

参考了OAuth2.0的简化模式(implicit grant type)设计了下面的方法。
接口使用方法:
1.接口调用者先申请分配一个clientid,clientsecret,并提供给接口提供者(服务器)一个可访问的callbackURL(用于接口access_token)。
2.接口调用者使用clientid, clientsecret作为参数,向接口提供者发送请求。
接口提供者访问callbackURL发送access_token(有时间限制,超时后重新获取)。
3.接口调用者使用access_token作为参数,调用其他接口获取相关信息。
4.接口调用者在access_token超时后重新获取access_token。

有个疑问:
仅为了防止非法用户随意使用接口,需要这个复杂的机制吗?
接口使用https连接,可以确保数据保密性。
所以是否可以简化上面的流程,仅在接口服务者中配置一个 access_token,
接口使用者只需要提供正确的access_token即可正常使用其他接口。


可以拿rsa在客户端与服务端进行校验,但是实际过程中发现效率很低,加解密消耗略大,每次请求都要来,后来改成夹带时间戳和sha256一下token了,扔到header头或者query中即可,写成中间件,我用的是nodejs,别的语言应该也可以这么设计。

反正就是你规定一个不好猜的机制来防止别人请求,做一个统一拦截器就好了。客户端app,正常都是rsa,但是一般公司不会做,当然,你可以一天校验几次,而不是每次都校验,做时效就好了,反正都是业务逻辑。

这样就算不是https的,也不怕,最多在时效间隔内被冒充请求。

至于网站本身的身份系统,我是这么处理的。


自己业务的session就行了,反正做好统一的权限界定,在proxy层再做下用户id的校验,应该就没问题,比如a用户不能写入b用户的接口数据,当然a可以请求写入数据接口,但是在proxy层会被错误拒绝就ok了。

选择 mongoose 的话可以在pre save中统一来做~

程序员 PHP API Web Service OAuth 2.0

JDK的OutputStream为什么方法write(int b)的入参类型是int呢?

-

根据JDK的实现,是忽略了高24位,直接写入低8位
既然是这样为什么入参不直接设计为byte呢?

题主在给文件系统写流式接口,感觉改成byte更符合语义一点,能避免用户一些使用错误。但是接口参考jdk用户可能用起来更顺手一点。采用哪种设计好呢?

因为read()方法会返回 0~255 以及 -1。
所以write()最好是设计成与read()相匹配的模式。
~~~~~~~
我们还可以注意到read(byte[])方法也会返回一个int
代表读取到的字节数,同样也可能返回-1代表已到达流末尾。
所以这里不需要使用int[],而是可以使用byte[]。
~~~~~~~
我想如果当初设计read()方法时,不是采用返回-1来代表流末尾,
而是抛出一个异常EOFException的话,用byte也是完全可以的。

API Java JDK源码

IFTTT 真的好用吗?

-

ifttt的概念让我激动,但是具体使用却总不尽人意,不是所有sns都开发api的,不是所有想要的东西都能整合进去,那么限制在特定数个应用圈子里的ifttt真的有那么好用吗?

我觉得平台是一种趋势,不论是大公司(如谷歌,facebook,腾讯都在做开放平台),还是一些“小”的公司(evernote,read it later)。这样的应用会越来越多,调用也会越来越方便,更多的帐号会被连接在一起。
当然,目前来说普及很难。说实话,这个东西对于很多网民(国内来说吧)来说,操作起来还很困难,对应用的理解还没到达if....else...then..的程度,也缺乏这样一种思维。国内类似的如果云等产品远远还没到可以让“草根”也随意使用的程度,局长们连微博都还需要培训使用,怎么可能来学习使用这么具有逻辑性的产品,甚至我身边的很多计算机专业同学尝试一下感觉不太会用就放弃了。
无论如何,我很喜欢ifttt,自己创造的感觉很不错

社交网络 用户体验 API IFTTT

© COPYRIGHT BY i How And Why.com 2015