讨论一下rest api的scalability问题

为了给简历增加亮点就写了一条曾经设计过scalable的rest api，结果每次都会被问题如何设计的，还会继续深挖细节，每次都答得很不好，下来查询了网上资料也没得到清晰答案。
不知道哪位大神可以针对rest api的scalable设计方面给出方向和实际的例子。

按本渣的想法就是按照reset的设计规范定义好方法名，比如是名词复数带版本号，还有带些合理的参数，然后套在类似spring的framework里实现里具体逻辑后，把编译完的代码部署到scalable的环境里就可以了吧。
肯定理解的非常粗浅，请诸位帮忙打开思路。

正常微服务化的API绝大部分都是stateless的，实际上stateful只有数据库，缓存这几个组件。但是你写Web service的时候API应该是不关心内部实现的，同一个API内部实现不同scalability也不同，但是API本身是一样的，所以我不觉得有所谓API的scalable，只有整个系统的scalability

可以读一读rest概念最早发明出来是怎么用的然后往上面套。比如get都是stateless的所以可以并行，可以cache之类的。 我就是定义一个 /gibberish 也并不会影响我系统的scalability，并不觉得naming跟这个话题有任何关系

baxia_lan 发表于 2020-3-27 01:44
可以读一读rest概念最早发明出来是怎么用的然后往上面套。比如get都是stateless的所以可以并行，可以cache ...

比如你一个server上运行了你的api，这个时候框架不就保证了你的get都是并行的，因为get的request很多啊，这个并行不是api的设计去保证的吧？ 是不是一个api设计首选需要保证stateless，而且cache的问题不是应该系统的组件之间连接来进行，和api之间是什么关系呢？多谢

TommyFox 发表于 2020-3-31 01:23
正常微服务化的API绝大部分都是stateless的，实际上stateful只有数据库，缓存这几个组件。但是你写Web serv ...

你的意思是除了call api的时候注意不要有stateful的情况外，scalable由项目和系统来保证，这个api的对应的后台程序是没什么scalable去考虑吧，因为后台的程序仅仅是响应request处理完逻辑后返回response