增删改查api接口文档（restframework增删改查api设计）

本篇文章给大家谈谈增删改查api接口文档，以及restframework增删改查api设计对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。 今天给各位分享增删改查api接口文档的知识，其中也会对restframework增删改查api设计进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、Django REST framework框架之GET, POST, PUT, PATCH, DELETE等API请求接口设计
• 2、APIJSON，鹅厂开源的零代码、全功能、强安全ORM库
• 3、iOS——HealthKit（苹果健康）的增删改查
• 4、Spring Boot整合ElasticSearch实现增删改查基本示例
• 5、RESTful API 设计约定
• 6、快递API哪个好用？

Django REST framework框架之GET, POST, PUT, PATCH, DELETE等API请求接口设计

一、API接口功能需求：设计一些接口URL，让前端/客户请求这个URL去获取数据并显示，更改数据（增删改查），达到前后端分离的效果

二、设计逻辑：通过http协议请求方式GET、POST、PUT、PATCH、DELETE设计符合RESTful规范的api接口也就是URL

三、简易源码：

3.序列化serializers
#导入模型类和rest_framework序列化模块serializers
from .models import Article
from rest_framework import serializers

#定义序列化类，使用继承ModelSerializer方法
class ArticleSerializer(serializers.ModelSerializer):
class Meta:
model = Article #指定序列化的模型类
fields = '_ all _' #选取序列化字段，此处可自行选取字段

4.视图函数views
from django.http import HttpResponse
from django.views.decorators.csrf import csrf_exempt
from .models import Article
from .serializers import ArticleSerializer
from rest_framework.renderers import JSONRenderer
from rest_framework.parsers import JSONParser
#调用csrf装饰器csrf_exempt模块，解决跨域访问问题
#JSONRenderer它将Python的dict转换为JSON返回给客户端
#JSONParser 负责将请求接收的JSON数据转换为dict

#写法一
#在需要跨域的视图上调用装饰器@csrf_exempt
@csrf_exempt
def article_list(request):
if request.method == 'GET':
arts = Article.objects.all() #获取模型类数据
ser = ArticleSerializer(instance=arts,many=True) #序列化数据instance
#下一步用rest_framework方法里的JSONRenderer方法渲染数据
json_data = JSONRenderer().render(ser.data)
return HttpResponse(json_data,content_type='application/json',status=200)

#写法二
class JSONResponse(HttpResponse):
def _ init (self,data,**kwargs):
content = JSONRenderer().render(data)
kwargs['content_type'] = 'application/json'
super(JSONResponse, self)._ init (content,**kwargs)

#根据id进行增删改操作接口
@csrf_exempt
def article_detail(request,id):
try:
art = Article.objects.get(id=id)
except Article.DoesNotExist as e:
return HttpResponse(status=404)

备注：
*写法二中定义JSONResponse类将返回的数据data与content_type返回类型做了封装
*API接口
GET/POST
api/articles
GET/PUT/PATCH/DELETE
api/articles/1
*Postman测试效果图

APIJSON，鹅厂开源的零代码、全功能、强安全ORM库

APIJSON是鹅厂开源出来的零代码、全功能、强安全的ORM库增删改查api接口文档，是一种专为 API 而生的 JSON 网络传输协议以及基于这套协议实现的库。为各种增删改查提供了 完全自动化的万能通用接口 ， 零代码 实时满足千变万化的各种新增和变更需求。

能大幅降低开发和沟通成本，简化开发流程，缩短开发周期。适合中小型前后端分离的项目，尤其是 初创项目、内部项目、低代码/零代码、小程序、BaaS、Serverless 等。

其社区非常活跃，生态完善，早已形成了 .net,python,php,go 等多语言的版本，增删改查api接口文档你能遇到的问题都能在这里解决。

数据库增删改查api接口文档：MySql5.7增删改查api接口文档；

数据库管理工具增删改查api接口文档：Navicat；

开发IDE：IntelliJ IDEA

1.下载后端源码

2.初始化数据库

运行Navicate，新建sys模式（如果存在则不用新建），运行sql文件（ sql文件位置：根目录MySQLsys.sql ）初始化数据表，执行成功后刷新会看到初始化后的数据表。

3.使用IntelliJ IDEA打开项目

打开 IntelliJ IDEA工具， File-Open ，选择” 解压根目录/D:MSourceAPIJSON-Demo-masterAPIJSON-Java-Server “文件夹下面的 APIJSONBoot项目，导入源码。

IDE工具会自动从加载所需的库文件。

打开 DemoSQLConfig类，编辑 getDBUri，getDBAccount，getDBPassword，getSchema 的返回值为你自己数据库的配置。

DemoSQLConfig.java

APIJSONDemo/APIJSONBoot: 右键 DemoApplication Run DemoApplication.main
APIJSONFinal: 右键 DemoAppConfig Run DemoAppConfig.main

在浏览器输入 http://localhost:8080/get/{}，如果出现以下代码段说明运行成功。

语法学习请参考官方文档：https://github.com/Tencent/APIJSON/blob/master/%E8%AF%A6%E7%BB%86%E7%9A%84%E8%AF%B4%E6%98%8E%E6%96%87%E6%A1%A3.md

使用 Apache License 2.0，对 公司、团队、个人 等 商用、非商用 都自由免费且非常友好，请放心使用和登记。

iOS——HealthKit（苹果健康）的增删改查

NSHealthShareUsageDescription：读取用户健康数据
NSHealthUpdateUsageDescription：更改用户健康数据

HealthKit是iOS8加入的API
HealthKit在iPad上不可用
通过HKHealthStore类方法 + (BOOL)isHealthDataAvailable;判断设备是否支持HealthKit

以体重为例，将体重写入至健康，

数据读取有多种方式，我主要说下HKSampleQuery（样本查询）和HKStatisticsCollectionQuery（统计集合查询）

HKSampleQuery 这是使用最多的查询。使用样本查询来读取任何类型的样本数据。当你想要对结果进行排序或者限制返回的样本总数时，样本查询就特别有用。更多信息，参见 HKSampleQuery Class Reference

HKStatisticsCollectionQuery ，使用这种查询来在一系列长度固定的时间间隔中执行多次统计查询。通常使用这种查询来生成图表。查询提供了一些简单的方法来计算某些值，例如，每天消耗的总热量或者每5分钟行走的步数。统计集合查询是长时间运行的。查询可以返回当前的统计集合，也可以监测HealthKit存储，并对更新做出响应。更多信息，参见 HKStatisticsCollectionQuery Class Reference 。

健康的数据只有添加和删除，所谓修改就是删除一条再添加一条。
我这里的思路，删除的依据是时间，对体重数据的修改只能修改数值，不能修改时间，所以查出同时间的数据，删除旧的，再添加新的。

Spring Boot整合ElasticSearch实现增删改查基本示例

ElasticSearch被命名为大数据搜索引擎增删改查api接口文档，在文件检索、数据存储方面具有天然增删改查api接口文档的优势。而SpringBoot作为服务整合中间件，在服务组装方面是一款万能粘合器，本文主要提供Spring Boot整合ElasticSearch基本增删改示例。

ElasticSearch安装过程可参考博主之前笔文:

https://www.toutiao.com/i6827758978567504392/

ElasticSearch基本介绍可参考博主之前笔文增删改查api接口文档：

https://www.toutiao.com/i6884427730096488971/

Maven工程引入:
org.springframework.boot

spring-boot-starter-data-elasticsearch
注意:ElasticSearch版本号与Spring Boot版本号是有关联的，本文笔者Spring Boot版本号是2.1.6，因此安装的ElasticSearch版本号是7.7.0。

package com.opendi.generator.elasticsearch.model;
import lombok.Data;

import org.springframework.data.annotation.Id;

import org.springframework.data.elasticsearch.annotations.Document;

import org.springframework.data.elasticsearch.annotations.Field;

import org.springframework.data.elasticsearch.annotations.FieldType;
import java.util.List;
@Data

@Document(indexName="post", type="post",shards=1,replicas = 0)

public class Post {

@Id

private String id;
private String title;
@Field(type=FieldType.Nested)

private List tags;

}

package com.opendi.generator.model;
import lombok.Data;
import org.springframework.data.annotation.Id;

import org.springframework.data.elasticsearch.annotations.Document;

import org.springframework.data.elasticsearch.annotations.Field;

import org.springframework.data.elasticsearch.annotations.FieldType;
@Data

@Document(indexName = "book", type = "_doc", shards = 1, replicas = 0)

public class BookBean {

@Id

private String id;

@Field(type = FieldType.Keyword)

private String title;

@Field(type = FieldType.Keyword)

private String author;

@Field(type = FieldType.Keyword)

private String postDate;
public BookBean(){}
public BookBean(String id, String title, String author, String postDate){

this.id=id;

this.title=title;

this.author=author;

this.postDate=postDate;

}
public String getId() {

return id;

}
public void setId(String id) {

this.id = id;

}
public String getTitle() {

return title;

}
public void setTitle(String title) {

this.title = title;

}
public String getAuthor() {

return author;

}
public void setAuthor(String author) {

this.author = author;

}
public String getPostDate() {

return postDate;

}
public void setPostDate(String postDate) {

this.postDate = postDate;

}
@Override

public String toString() {

return "BookBean{" +

"id='" + id + ''' +

", title='" + title + ''' +

", author='" + author + ''' +

", postDate='" + postDate + ''' +

'}';

}

}
package com.opendi.generator.elasticsearch.mapper;
import com.opendi.generator.elasticsearch.model.Post;

import org.springframework.data.domain.Page;

import org.springframework.data.domain.Pageable;

import org.springframework.data.elasticsearch.repository.ElasticsearchRepository;
public interface PostRepository extends ElasticsearchRepository {

Page findByTitle(String title, Pageable pageable);

}

package com.opendi.generator.dao;
import com.opendi.generator.model.BookBean;

import org.springframework.data.domain.Page;

import org.springframework.data.domain.Pageable;

import org.springframework.data.elasticsearch.repository.ElasticsearchRepository;
/**

* 接口关系：

* ElasticsearchRepository -- ElasticsearchCrudRepository -- PagingAndSortingRepository -- CrudRepository

*/

public interface BookRepository extends ElasticsearchRepository {
//Optional findById(String id);
Page findByAuthor(String author, Pageable pageable);
Page findByTitle(String title, Pageable pageable);
}
使用了ElasticSearch里面的操作工具对数据进行操作。

package com.opendi.generator.elasticsearch.service;
import com.opendi.generator.elasticsearch.model.Post;

import org.springframework.data.domain.Page;

import org.springframework.data.domain.PageRequest;
import java.util.Optional;
public interface PostService {
Post save(Post post);
Optional findOne(String id);
Iterable findAll();
Page findByTitle(String title, PageRequest pageRequest);

}

指定操作对象:

package com.opendi.generator.elasticsearch.service.impl;
import com.opendi.generator.elasticsearch.mapper.PostRepository;

import com.opendi.generator.elasticsearch.model.Post;

import com.opendi.generator.elasticsearch.service.PostService;

import org.springframework.beans.factory.annotation.Autowired;

import org.springframework.data.domain.Page;

import org.springframework.data.domain.PageRequest;

import org.springframework.stereotype.Service;
import java.util.Optional;
@Service

public class PostServiceImpl implements PostService {
@Autowired

private PostRepository postRepository;
@Override

public Post save(Post post) {

postRepository.save(post);

return post;

}
@Override

public Optional findOne(String id) {
return postRepository.findById(id);

}
@Override

public Iterable findAll() {

return postRepository.findAll();

}
@Override

public Page findByTitle(String title, PageRequest pageRequest) {

return postRepository.findByTitle(title, pageRequest);

}

}

package com.opendi.generator.service;
import com.opendi.generator.model.BookBean;

import org.springframework.data.domain.Page;

import org.springframework.data.domain.PageRequest;
import java.util.List;

import java.util.Optional;
public interface BookService {
Optional findById(String id);
BookBean save(BookBean blog);
void delete(BookBean blog);
Optional findOne(String id);
List findAll();
Page findByAuthor(String author, PageRequest pageRequest);
Page findByTitle(String title, PageRequest pageRequest);

}
package com.opendi.generator.service.impl;
import com.opendi.generator.dao.BookRepository;

import com.opendi.generator.model.BookBean;

import com.opendi.generator.service.BookService;

import org.springframework.beans.factory.annotation.Autowired;

import org.springframework.beans.factory.annotation.Qualifier;

import org.springframework.data.domain.Page;

import org.springframework.data.domain.PageRequest;

import org.springframework.stereotype.Service;
import java.util.List;

import java.util.Optional;
@Service("blogService")

public class BookServiceImpl implements BookService {
@Autowired

@Qualifier("bookRepository")

private BookRepository bookRepository;
@Override

public Optional findById(String id) {

//CrudRepository中的方法

return bookRepository.findById(id);

}
@Override

public BookBean save(BookBean blog) {

return bookRepository.save(blog);

}
@Override

public void delete(BookBean blog) {

bookRepository.delete(blog);

}
@Override

public Optional findOne(String id) {

return bookRepository.findById(id);

}
@Override

public List findAll() {

return (List ) bookRepository.findAll();

}
@Override

public Page findByAuthor(String author, PageRequest pageRequest) {

return bookRepository.findByAuthor(author,pageRequest);

}
@Override

public Page findByTitle(String title, PageRequest pageRequest) {

return bookRepository.findByTitle(title,pageRequest);

}

}

会调用ElasticSearch底层功能进行操作，能够实现ElasticSearch增删改操作。

连接服务器ElasticSearch连接配置:

spring:

data:

elasticsearch:

cluster-name: es2018

cluster-nodes: 10.172.8.154:9300

repositories:

enabled: true

elasticsearch:

jest:

uris: http:// 10.172.8.154:9200

增加连接配置,这样就能连接ElasticSearch客户端了。

ElasticSearch在Controller操作:

package com.opendi.generator.controller;
import com.opendi.generator.model.BookBean;

import com.opendi.generator.service.BookService;

import org.springframework.beans.factory.annotation.Autowired;

import org.springframework.web.bind.annotation.PathVariable;

import org.springframework.web.bind.annotation.RequestMapping;

import org.springframework.web.bind.annotation.ResponseBody;

import org.springframework.web.bind.annotation.RestController;

import java.util.Optional;
@RestController

public class ElasticController {

@Autowired

private BookService bookService;
@RequestMapping("/book/{id}")

@ResponseBody

public BookBean getBookById(@PathVariable String id){

Optional opt =bookService.findById(id);

BookBean book=opt.get();

System.out.println(book);

return book;

}
@RequestMapping("/save")

@ResponseBody

public void Save(){

System.setProperty("es.set.netty.runtime.available.processors", "false");

BookBean book=new BookBean("1","ES入门教程","程裕强","2018-10-01");

System.out.println(book);

bookService.save(book);

}
}
package com.opendi.generator.elasticsearch.controller;
import com.opendi.generator.elasticsearch.model.Post;

import com.opendi.generator.elasticsearch.model.Tag;

import com.opendi.generator.elasticsearch.service.PostService;

import io.swagger.annotations.Api;

import io.swagger.annotations.ApiOperation;

import org.springframework.beans.factory.annotation.Autowired;

import org.springframework.data.domain.Page;

import org.springframework.data.domain.PageRequest;

import org.springframework.web.bind.annotation.GetMapping;

import org.springframework.web.bind.annotation.RestController;
import java.util.ArrayList;

import java.util.Arrays;

import java.util.List;
@Api(tags="ElasticSearch示例")

@RestController

public class PostController {
@Autowired

private PostService postService;
@ApiOperation(value="得到ES结果")

@GetMapping(value="getList")

public List<page getList()</page

{

List<page list = new ArrayList<page ();</page </page

Tag tag = new Tag();

tag.setId("1");

tag.setName("tech");

Tag tag2 = new Tag();

tag2.setId("2");

tag2.setName("elasticSearch");

Post post = new Post();

post.setId("1");

post.setTitle("This is post");

post.setTags(Arrays.asList(tag,tag2));

postService.save(post);

Post post2 = new Post();

post2.setId("2");

post2.setTitle("Biding2");

post2.setTags(Arrays.asList(tag));

postService.save(post2);

Page posts = postService.findByTitle("This is post", new PageRequest(0, 10));

Page posts2 = postService.findByTitle("Biding2", new PageRequest(0,10));

Page posts3 = postService.findByTitle("Biding2", new PageRequest(0,10));

list.add(posts);

list.add(posts2);

list.add(posts3);

return list;

}

}

控制台打印:

RESTful API 设计约定

本文编写目的是为了尽可能的约定好一个公司的产品、组件、项目开发的RESTful API 设计风格，使不同团队间设计的API风格尽量一致，减少项目后期由于规范问题或设计不足导致的接口重构造成的开发、测试返工。最终让接口的最终使用者能够在开发过程中有个良好的体验。

此约定可作为开发人员设计RESTful 接口或项目接口发布评审的参考。

个人观点：用了 JSON-RPC 不等于 是RESTful API ，RESTful API通常是基于HTTP/JSON方式实现的 ，两种方式的API设计方式都不错，项目中选适合的就好。简单对比如下：

本文仅是作者个人根据主观喜好和接口设计经验搜罗总结而来的RESTful API设计约定，仅作为接口设计的基本要求，也欢迎与大家讨论。此约定未涉及超文本HATEOAS相关内容，也不包含RPC类面向后端服务方法映射接口的范畴。

API 是后端应用程序的脸面(UI)，用户体验非常重要。尤其是当你开发的是一个可复用的组件或产品，如果API设计有些许瑕疵，会直接影响开发者的体验，设计者会被骂的…… 有问题的API一旦开放出去了，哪怕是简单的拼写错误，由于要保持兼容性不能删改，会成为技术欠债长期背下去。

以上关键点不只适用于RESTful API，其他类型API也是一样的。

作为对外公开发布的RESTful API，根URL中一般要有域名与版本信息。通常一个WEB站点会同时提供网站服务和API服务，我们需要根据URL能够区分出访问的是服务接口还是网站中的网页、文件等资源。因此RESTful API的根URL中根据不同场景一般会在一级域名中或者是子域名中带api关键字。

常见的两种根URL用法如下：

推荐的方案是根URL中采用子域名的方式区分API，即： https://iam.primeton.com/api/v1/*

路径终点即粗体部分内容： https:// example.org/api/v1/ menus

设计RESTful API时常用的HTTP Method包括：GET、POST、PUT、PATCH、DELETE 简单说明如下：

根据资源标识可以 唯一定位一个资源 时，建议使用URL路径参数方式传递。对应Springboot 的 @PathVariable 。API Path示例如下：

根据资源属性查询过滤 一或多个资源 时，建议使用URL查询参数方式传递。对应Springboot的 @RequestParam 。API Path示例如下：

对于简单查询类接口，可以使用路径参数和查询参数解决，如果是复杂功能型查询接口中需要通过复杂的过滤条件查询时如： < in between 等等，查询参数用起来会非常痛苦，GET Method又不支持提交Request Body参数。因此我建议这种 复杂型查询采用POST Method 提交到一个特定的Path上 。参见如下场景：

查询接口返回多个数据时，需要支持分页（枚举类数据或少量数据除外）和排序。

如需使用分页查询和排序，建议统一请求与响应报文结构，格式如下：

请求参数示例：

GET /users?page=1size=5sort=username

单页数据响应结果示例：

上述分页排序与响应报文格式是来自Spring Data定义的模型，为了保持分页排序接口相关的使用习惯，如果持久化不使用JPA，仍然建议采用上述规范的报文定义封装接口。为使用者提供一致的体验。

如果资源需要做一些增删改之外的操作（如状态变更），可以用 /actions 作为path

例如：流程平台中的流程实例会有状态变化，如启动、挂起、恢复、终止等等，这种接口建议这样设计：

组合资源，即两种资源之间存在组合关系，组合指整体与部分的强包含关系，但整体与部分是不可分的，整体的生命周期结束也就意味着部分的生命周期结束。对"部分"的操作一定会由整体作为入口，不会直接跳过"整体"来对"部分"做增删改查。这种组合场景中，推荐API设计方式示例如下：

聚合资源，即两种资源之间存在聚合关系。聚合也是整体与部分的弱包含关系，但整体与部分之间是可分离的，他们可以具有各自的生命周期，部分可以属于多个不同的主体对象，也可以为多个整体对象共享。

例如，机构或角色下包含人员，需要获取机构或角色下的人员的场景，避免做成分别通过机构入口或角色入口找人等重复的具有类似功能的接口：

在RESTful API设计中，正常和异常情况建议通过HTTP约定的status进行区分， 不建议 采用所有接口均POST Method调用，永远返回200这种模式。

推荐的常用Http Status说明如下：

HTTP 1.0 Status 详细说明参考

API调用成功后，返回HTTP 2xx状态码，Response Body直接返回业务数据即可。请求和响应报文建议统一采用JSON格式。

RESTful API 对于异常报文需要规范和统一，服务端出现异常情况下，需要进行全局拦截，然后将异常信息封装为规范的格式，返回给调用端。

对于后端的异常信息，建议包含编码和消息

本文是基于学习各路大神们对RESTful 设计相关文章，结合自己设计接口时遇到困惑后的解决方案，收集与总结而成的RESTful API设计约定。部分内容夹杂个人喜好与主观观点，抛砖引玉，希望能为大家设计API带来些许帮助。后如果遇到一些更复杂的场景，欢迎一起沟通。

快递API哪个好用？

如果增删改查api接口文档你增删改查api接口文档了解了API，才可能对各家的广告系统有更深刻的了解。

数字广告人，对各家媒体的广告产品有所了解，对它们的广告系统要有所了解，而对它们的API，则更值得了解。

可是，对于普通的数字营销人，如果不是搞技术或者搞广告产品，并不情愿去了解API，因为大家都会觉得，这不是技术干的活嘛。

这个观点绝对是非常局限的。API的价值在于，它能够实现广告系统默认功能之外的更强大的功能，或者让原有的功能变得更强。

如果你了解了API，才可能对各家的广告系统有更深刻的了解。当然，作为数字营销人，你不需要了解API背后的编程，你知道它们的强大就足够了。

全文目录如下：

一、API的本质

二、API比你想象的还要野

三、广告系统的API有哪些作用

四、API带来了哪些人手工不能完成的功能

五、各主流媒体广告平台的API

六、API的坑：除了自己开发，更简单的办法是利用第三方服务

（全文5000字，大约阅读时间15分钟。）

一、API的本质：

API的本质是传递数据。它跟USB接口特别类似。数据可以传进，也可以传出。

利用这个传输数据的接口，广告系统之外的系统，可以操控广告系统增删改查api接口文档；而广告系统，也可以利用外部的系统扩展自己的功能。

尽管我们这篇文章写广告系统的API，但实际上，几乎所有的SaaS系统，都提供API接口。不，应该更准确地说，是几乎所有今天的编程产品，都提供API接口。为的就是让自己变得更强大更有用。

是的，它跟我们电脑的USB太像了。你几乎见不到不提供USB的电脑，你也几乎见不到不用API的互联网产品。

二、API比你想象的还要野

我们可能以为API不过是“部分地”传递数据的接口罢了。

但API能做到的事情，比我们想象中的要野的多。理论上，通过API能够把一个系统所有的数据和功能传输到系统之外，从而可以在这个系统之外“复制”一个同样功能和数据的系统。比如，Google Analytics提供的API，可以让你在本地搭建一个跟Google Analytics报表功能几乎完全一样的复制系统，数据源源不断从谷歌分析中来，但界面却可以完全是你自己公司的。——这样，其实也完美解决了不*科*学*上*网*不能用GA的问题。

再比如，最近流行的低代码开发平台维格表，也是支持API的数据表，通过一个简单易用的数表软件对接各种业务系统API，搭建出1000+系统：项目管理系统、电商数据运营系统、店铺管理系统等。

所以，API绝对是个好东西，它非常强大，强大到任何数据和操作，都可以透过API完成。包含的功能全只是API能力的一个方面，API更大的能力是——它是机器人呀。所以，尽管API做的事情全部都可以手工替代，但是API可以一秒钟做到人一万次甚至百万次的操作。这样，量变引发了质变，利用API就产生了一些人手工实现不了的功能。所以，某种程度上，可以说是API让很多广告投放操作员失去了工作。

三、广告系统的API有哪些作用

回到广告系统的API上来。广告系统的API一方面是对广告平台原本的功能进行升级，最简单的如批量操作是在操作对象的量级上进行升级；另一方面，它可以增加广告原本没有的功能，例如，跨媒体的素材管理功能。

那么，广告系统的API是如何实现这些功能的呢？

给外部系统提供各种广告投放数据；接受外部的控制指令；接受外部提供的各种增强功能相关的数据。好了，下面具体说说这三方面的能力。

广告系统的API提供什么数据理论上，API可以提供关于广告账户的所有数据。我们对各大主流的广告平台进行整理，它们提供的数据基本都包含下面五个方面：账户数据、投放数据、用户数据、报表数据和设备信息等等。当然，各个广告平台还有各自不同的特点，所以有些广告系统还会提供其他的数据。例如，DMP人群数据等等。广告系统的API接受什么样的外部控制指令广告系统的API的功能，包含大部分的账户操作，如计划、单元、创意和图片，具体的功能基本相近，都是创建、修改、删除和查询。

广告系统的API接收哪些常见的增强功能除了基础的增删改查的功能外，不同的广告平台也提供特定的功能。

四、API带来了哪些人手工不能完成的功能

广告系统提供的API接口，就像一个个的乐高积木。

广告主、代理商和第三方工具服务商（例如前文提到的维格表VIKA.CN），可以根据自己的业务需求，搭建自己的系统模型。让广告投放变得更加自动化、智能化和个性化。

特别是对业务线广和账户数量多的客户来说，利用好广告系统的API功能能实现对现有投放业务的升级。

API具体能实现的功能很多，列举了常见的几种如下：

功能一：批量投放通过API接口调用，轻松实现广告的批量创建、修改等操作。以百度信息流的API为例，通过调用创意层级的接口功能，可以分30次批量上传9万条创意。最大程度的解决人工操作固有的耗时长、效率低的问题。

功能二：一站式的素材管理跨媒体的素材+创意自动组合投放和以素材维度的数据报表都能通过API实现。什么意思呢？同一个素材，用在头条、百度等多个信息流平台。原本投放前需要分别上传，投放后又需要分别汇总数据进行分析。而API接口通过将媒体与媒体关联，可以实现一站式投放。无需重复上传物料，而且还能查看素材维度的报表，分析素材在各个平台和账户上的数据表现。

功能三：智能出价不同广告主的投放各有不同，针对如oCPA投放的广告，可以根据自定义的优化目标，例如激活、注册、购买，再依据转化目标设定转化出价。广告系统将自动对投放进行智能优化，精准触达高转化率用户。

功能四：自动化预警通过API可以设置自动化规则，并依据监测目标进行指定操作。如，当转化成本超过设置目标后，可以自动暂停计划避免更大的消耗。或者，当投放效果稳定时，自动提升预算延长投放时间。减轻人工监控的负担和管理成本。

功能五：人群包自动更新主要是针对APP下载投放的广告主，重复投放已下载的用户无疑是一种浪费。而利用API完全可以实现人群包的自动更新。设置一个固定时段如24小时，自动上传已下载用户的人群标识如手机号，不再对此人群包进行投放即可。

功能六：前后链接数据打通和定制化报表报表整理无疑是最繁琐，但又是最必不可少的工作之一。通过API不仅可以解放手工拼接报表的负担，而且还可以查看自定义报表。系统除了能同步更新报表，还能实现前后链路打通的异步更新报表。

功能七：多角色管理主要是针对多账户的广告主和代理商，解决频繁切换账户的问题。使用API可以搭建自己的平台实现多角色管理，避免频繁的账号切换、同时还有子客户开通能力和划账能力。

五、各主流媒体广告平台的API的特点

目前主流的广告平台都已开放API接口，有开发能力的广告主、代理商和第三方都可接入API，搭建满足自身个性化营销需求的内部工具。

不过，在具体对接实用时，要注意各个广告平台的特点。

维格表vika API巨量引擎是维格智数科技旗下官方品牌，全面开放的巨量引擎维格表 API提供的是一套完善的投放平台功能的接口服务。这也是其投放闭环中的重要一个环节，重点是帮助广告主提高广告投放效果。

维格表API将原本投放平台的功能拆解为一个个独立的API接口，每个API接口都能完成独立的操作。

例如，创建计划的接口、获取技术的数据接口等。维格表将其划分为四个模块的权限：账户服务、广告投放、DMP人群管理和数据报表。

这种打包模式，更加便于申请使用。此外，维格表还将自己其他的功能也通过API的形式开放出来，包括：动态商品广告和工具。动态商品广告主要是基于该用户之前与该商品的互动行为，针对该用户展开该商品的再营销展示对于的商品信息。

有效利用维格表 API不仅能解决之前大量需要人力完成的工作，更重要的是，可以实现智能化的投放管理。不过，具体实现要看开发者的技术能力。

腾讯社交广告Marketing API腾讯社交广告以其Marketing API为基础的平台生态是非常开放。他们本身的定位，就是通过API将整个广告平台的能力，输入到各个小生态中对其赋能。首先，针对有较技术实力的广告主，他们本身就拥有自己的投放系统和工具。通过对接腾讯Marketing API，可以实现广告投放效率提升。而对代理商来说，腾讯Marketing API可以解决跨平台、多账户的投放数据和物料的整合分析问题。

这个之前，往往是依靠一支人数巨大的优化师团队来进行的。对于本身就有很强的开发能力的第三方工具商来说，API接口实现对腾讯广告系统功能的补充。

阿里汇川是效果类广告投放系统，包含在UC浏览器、UC头条，神马搜索，淘宝手机助手等平台的广告投放。汇川投放 API主要是为了实现企业的迅速扩量、成本控制、稳定投放的推广目标。

汇川API在开放的进程上，相较于其他家是比较晚的。在今年的4月份左右，才完成全量开发。目前，已能提供全面提供完善的接口服务，包括账户服务、物料服务、数据服务和DMP服务。不过，在具体使用的时候，汇川API在操作的量级上有较多限制。例如，账户预算的修改次数、修改的频率和生效时间都有明确的次数限制。

六、注意API的坑

API功能强大，因此广告主和代理商均值得拥有这样的“神器”。

不过，接入API还是有一些要注意的坑的。部分广告媒体的API是有条件开放的广告平台开放的API权限都是“低配版”，如果在具体的使用很可能需要不断申请提升配置，甚至是“定制化”的要求。但这对大多数的企业是有难度的。

权限限制对于普通的广告主来说，可以使用的仅仅是广告平台已开放的API功能。特殊需求，只有深度合作的企业平台才会开放。当然，所谓深度合作可能跟广告投放的预算有直接关系。配额限制例如，百度搜索的API的配额是有限制。且与账户的消耗挂钩，当配额不足时需要单独申请，才能正常使用。

频次限制例如，在今日头条的MARKETING API中app ID调用频次默认是1000次/分钟。这个默认值对大型代理商或第三方服务工具厂商来说是不够的，需要另外单独申请。同时申请难度也是随着需要的增加而增加。技术开发的坑多。

API本身只是提供一个接口，要如何使用这个接口是要重点考虑的问题？

第一，你要有不错的技术开发能力，可以搭建满足自己需求的广告营销平台。

第二，你的技术人员要了解实际的应用场景。不能被API本身的要求所迷惑，能兼容业务的变化需求。例如，在数据表结构的设计上，没有考虑公司业务会增加，最初的表结构缺少扩展性，接入的数据增加后又不得不重新修改。

第三，要有能同时对接多广告平台API，实现跨平台广告投放管理的能力。多媒体的广告投放是常态，仅仅能对接单一广告平台的API是不够的，如何能将目前所有的广告平台进行一站式的管理，也是提升广告投放效果的关键。

除了自己开发，更简单的办法是利用第三方服务专业的人做专业的事情，是避免踩坑的最好方式。

如果，你既想要享受API带来的便利，又不想费力去从零开始，可以直接使用第三方工具，实现API的一站式对接。例如利用维格表（vika.cn）这样的工具来解决问题。

这样的工具的最大价值在于，你不需要担心自己是否开发能力。傻瓜式的操作，就能使用各家广告平台的API的功能。具体操作很简单，简单设置后对应广告系统的API就可以透过维格表使用了。

这个工具支持大部分的广告系统，并且可以允许用户在一个界面中管理所有的。这是利用API最省力的方式。

关于增删改查api接口文档和restframework增删改查api设计的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 增删改查api接口文档的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于restframework增删改查api设计、增删改查api接口文档的信息别忘了在本站进行查找喔。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。