REST API专注于它所暴露的问题域(problem domain)的基础实体，而不是操纵这些实体的一组函数。
按照前言中介绍的示例，假设我们的议题(问题域)是”如何追踪狗及其主人“。 我们可能公开的主要实体包括：
1、狗狗的集合：它的url可能是 https://dogtracker.com/dogs. 2、单独的狗：每条狗都单独有一个url。我们稍后将讨论其URL格式。我们还需要类似狗的主人的一些信息。若给定一条狗的URL并了解过HTTP协议的工作原理，您已经知道如何做很多事情了。
例如，您若是想知道如何使用GET方法检索狗的详细信息，如何使用DELETE方法删除狗，以及如何使用PATCH或者PUT方法修改狗的属性……，若要出色地完成上述操作（get/delete/patch/put），您不得不同时了解狗的特性，以及http的操作原理。
如果狗具有相关的实体，例如“所有者”或“病史”，则可以用类似的方式(get/delete/patch/put)操纵这些实体。
同样，给定一组狗的URL，您已经知道如何使用POST方法创建新狗，并使用GET查找现有狗。 您可能必须学习如何过滤集合以缩小搜索范围，但是在设计良好的API中，可以通过给查询的URL添加参数来完成对集合的过滤查询。
相比之下，在面向函数(function-oriented)的API中，可变性更大，您必须学习更多的细节。 考虑以下示例表：
...
...
/getAllDogs
/getAllLeashedDogs
/verifyLocation
/verifyVeterinarianLocation
/feedNeeded
/feedNeededFood
/createRecurringWakeUp
/createRecurringMedication
/giveDirectOrder
/doDirectOwnerDiscipline
/checkHealth
/doExpressCheckupWithVeterinarian
/getRecurringWakeUpSchedule
/getRecurringFeedingSchedule
/getLocation
/getHungerLevel
/getDog
/getSquirrelsChasingPuppies
/newDog
/newDogForOwner
/getNewDogsSince
/getNewDogsAtKennelSince
/getRedDogs
/getRedDogsWithoutSiblings
/getSittingDogs
/getSittingDogsAtPark
/setDogStateTo
/setLeashedDogsStateTo
/replaceSittingDogsWithRunningDogs
/saveDog
/saveMommaDogsPuppies
...
...
要使用由此类功能组成的API，您必须了解什么是狗，及其内在属性是什么，但是您还必须学习很多特定于API功能的细节。 该细节没有明确的结构或模式可用于帮助您学习，因此学习负担很大，并且您所获得的知识将无法帮助您学习所需的下一个API。 这种样式的API之间几乎没有共同的元素。
将API基于HTTP和REST来设计的很大一部分原因在于http和rest对API带来的一致性。
将API设计基于HTTP和REST的价值的很大一部分来自于API带来的一致性。 本质上，当您本机使用HTTP时，您根本不需要发明API，HTTP提供了API，您只需在资源中定义数据即可。 在REST中，这种想法称为统一接口约束。
如下几个方面对于API设计都是非常重要的，他们共同定义了您的API：
1、资源表示（representations of resource）- 这包括了在资源中字段的定义（假设您的资源表示形式是结构化的，而不是字节或字符流），以及到相关资源的链接。 2、HTTP标头的使用标准 - （有时是自定义） 3、URL和URI模版 - 定义API的查询接口以根据其数据定位资源。 4、客户的必要行为 - 例如，DNS缓存行为，重试行为，资源中以前不存在的字段的容忍度等等
