Ich verstehe den wirklichen Unterschied zwischen der Web- und der API-Methode nicht ganz.
Ich habe nur das Gefühl, dass die Web-Methode der Front-End-Präsentation über den Browser entspricht, während die API der Mobiltelefon-/Tablet-Präsentation über die App entspricht
Darüber hinaus kann die Webmethode den Status (Sitzung, Cookie) auf natürliche und einfache Weise aufrechterhalten, während die API zustandslos ist, der Status jedoch künstlich mit Token aufrechterhalten werden kann.
Ich weiß nicht, ob dieses Verständnis richtig ist? 【Frage 1】
Gibt es ein Ajax-Problem mit der API-Methode? 【Frage 2】
Ich habe Laravel verwendet, um nach und nach einen rudimentären Prototyp einer Website zu erstellen (natürlich im Webmodus), und ich denke darüber nach, in Zukunft das entsprechende Frontend für Mobil-/Tablet-Apps zu entwickeln Alle Webzugriffe, egal ob Browser oder App? Alle sind über die API mit dem Backend (Server) verbunden. Auf diese Weise muss ich nicht das webbasierte Backend entwickeln, sondern nur das API-basierte Backend.
Ist das möglich? 【Frage 3】
Ist das einfach umzusetzen? 【Frage 4】
Ist dies eine gängige Branchenpraxis? 【Frage 5】
Vielen Dank im Voraus!
问题1:基本正确。用token不能算维持状态,只是一个临时的访问令牌而已。
问题2:后端API并不关心前端是不是ajax,毕竟ajax只是web的技术,而API可以接收各种类型的HTTP请求。web的ajax唯一需要注意的是跨域问题。
问题3:当然可行,这就是典型的前后端分离web开发。
问题4:容易,前端和后端可以完全独立开发,只需要API接口约定好。
问题5:其实已经通行很久了,不过你能独立悟出这一点也是不错的。
当然可以,所有前端与服务端的交互都通过api接口进行
关于pc端与app端公用同一套代码api实现的问题,有好处也有不好的地方,因为app受界面的限制,呈现的内容与pc应该还是有区别的,所以分开维护实现比较好,当然也有不好的地方,就是代码修改起来就要修改两个地方,所以还是看自己的综合考虑吧
我感觉如果产品服务需要衍生到很多平台,那就用API的方式开发。而且是各平台的功能、内容都高度耦合。
如果是网站功能很繁多、运营以网站为主,而APP简化了很多,这时候也可以独立给APP做个API,网站还是用传统的方式开发效率高一点。
前后端分离对SEO不太友好。
为了兼顾SEO和前后端分离而让后端换语言就有点太花费时间了