您可以使用框架为您完成很多工作，但在后台发生的事情并不是什么神奇的事情。在某种程度上，URI 映射到一些数据库表。它们不是指某个目录结构，而是试图解释资源之间的层级关系。
例如，假设我们正在为一所大学建模。数据库中的元素存储在 Faculties 或 Courses 两个表之一中。 Faculties 表由描述法学院、医学院等的行组成。它有一个独特的 faculty_id 列，然后是用于描述我们需要的任何内容的列。 Courses 表有一个唯一的 course_id 列和一个外键 faculty_id 列，以告知该课程属于哪个学院。
设计此 API 的 RESTful 方式可能是
-
/faculties 获取所有院系的列表，使用 SELECT * FROM Faculties 检索
-
/faculties/2获取某院系的信息，用SELECT * FROM Faculties WHERE faculty_id=2检索
-
/faculties/2/courses获取属于某个学院的所有课程，用SELECT * FROM Courses WHERE faculty_id=2检索
-
/faculties/2/courses/15检索某个课程，如果确实属于教员2，使用SELECT * FROM Courses WHERE faculty_id=2 AND course_id=15检索
具体实现取决于您选择的编程语言（可能还有框架），但有时您需要选择查询数据库的方式。这并不明显。您需要仔细计划它才有意义！
当然，来自数据库的结果必须以某种方式编码，通常是 XML 或 JSON（但其他表示形式也一样好，虽然可能不那么常见）。
除此之外，您还应该确保正确实现这四个动词，以便它们与 SQL 命令匹配（GET=SELECT、POST=INSERT、PUT=UPDATE、 DELETE=DELETE)，正确处理编码协商，返回正确的 HTTP 响应代码以及 RESTful API 所期望的所有其他内容。
作为最后一条建议：如果您能巧妙地做到这一点，那么您设计移动应用程序将变得轻松得多。我真的不能强调这一点。例如，如果您在 POST 请求中返回现在在数据库中查看的完整条目，您可以立即使用正确的 ID 将其存储在手机上，并且您可以使用相同的代码来呈现内容如果它是使用GET 请求下载的。此外，在您知道请求是否成功之前，您不会通过过早更新来欺骗用户（手机经常失去连接）。
编辑：在 cmets 中回答您的问题：创建 API 可以被视为一种艺术形式，并且可能不应该在设计阶段涉及任何编码。 API 应该是有意义的，并且不依赖于特定的实现（即不同的数据库选择不应该影响您的 API）。您的下一个任务将是在 API 的人类可读结构和您的数据库之间建立联系（无论它是关系型还是其他）。所以是的，你需要做一些翻译，但我看不出查询字符串对你有什么帮助。典型的结构是api.my.website/collection/element/collection/element。查询可用于过滤。例如，您可以编写 example.com/resource?since=2012-06-01 以从您的“资源”集合中检索元素的子集，但此特定查询的含义是检索您无法用唯一 ID 表达的内容。
按照我的理解，您认为传入的请求必须始终根据 PHP 和 HTTP 服务器的工作方式转到单独的文件。这不是的情况。你可以configure your web server to route every request to a single PHP file，然后解析$_SERVER['REQUEST_URI']。根据您选择的 HTTP 服务器，您的工作量可能会有所不同，但这基本上是您想要做的。
通过谷歌搜索，我找到了a list of frameworks for PHP，但我一个都不认识。不过还有其他人，我最近也听到有人提到Apify，尽管我也不能告诉你太多。 PHP 可能是实现 API 的更常见的选择之一。然而，cURL 是一个库/工具，据我所知，它仅用于连接到其他 网站。你当然可以使用the command line version of it 来调试你的API，但我认为你在服务器端用处不大。