[
https://issues.apache.org/jira/browse/SQOOP-1509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Veena Basavaraj updated SQOOP-1509:
-----------------------------------
Description:
See the attached DOC that explains the Rest APIs for the Sqoop entities
------------------------------------
Connector APIs ( read only)
1 ) v1/connectors - GET ( lists all connectors)
2 ) v1/connector/:cname - GET (fetch a connector identified by cname)
3) v1/connector/:cname/links - GET ( get all links associated with connector
cname)
-----------------------------------
Link APIs
We create a link per connector. Hence the api list the parent/child
relationship.
1) v1/connector/:cname/link GET - gets the params list required for this link
object ( used in the context of UI )
2_ v1/connector/:cname/link POST - creates a link for the connector ( since we
have the connector name we can show the correct inputs/params for this link to
be filled in)
3) v1/link/:lname GET/DELETE/PUT ( supports fetch/delete/updating a link object
for the given lname)
4) v1/link/:lname/enable (action for enabling a link)
5) v1/link/:lname/disable ( action for disabling a link )
--------------------------------------
NOTE: I am using params for configs ( since config and params go hand in hand,
rather than config and inputs )
Config APIs ( might need some more thinking, open to suggestions)
ctype can be mainly 3 of them ( from, to, driver )
1) v1/config/:cftype/link/:lname - GET ( will fetch all the config params/
inputs for this link)
2) v1/config/:cftype/link/:lname - POST will create the from/to config for this
link
3) v1/config/driver/ POSTand GET ( version can be part of the driver config )
Note : We will also support creating driver configs per job Id and connector Id
if need be ( they will be POST data )
4) v1/config/:cfName ( DELETE/UPDATE/GET) for any config object.
-----------------------------------------
Job APIs
1) v1/job POST ( it will provide the fromConfig/toConfig/driverConfig map ) to
create a job
Note: driverConfig is not required, it is optional. If not given we will use
the default driver config created as part of the Sqoop system
2) v1/job/:jname - DELETE/UPDATE/GET
3) v1/job/:jname/from - GET only the from config info for this job
4) v1/job/:jname/to - GET only the to config info for this job
5) v1/job/:jname/driver - GET only the driver config info for this job if it
exists
6) v1/job/:jname/enable
7) v1/job/:jname/disable
8) v1/job/:jname/start ( the most important one !!)
9) v1/job/:jname/stop
---------------------------------------------------
Submissions APIs ( read only)
1) v1/job/:jname/submissions - GET ( gets all the submissions)
2) v1/submission/:sname - GET a submission with the sname ( I hope there is a
submission Id/ name we support)
was:
See the attached DOC that explains the Rest APIs for the Sqoop entities
------------------------------------
Connector APIs ( read only)
1 ) v1/connectors - GET ( lists all connectors)
2 ) v1/connector/:cname - GET (fetch a connector identified by cname)
3) v1/connector/:cname/links - GET ( get all links associated with connector
cname)
-----------------------------------
Link APIs
We create a link per connector. Hence the api list the parent/child
relationship.
1) v1/connector/:cname/link POST - creates a link for the connector ( since we
have the connector name we can show the correct inputs/params for this link to
be filled in)
2) v1/link/:lname GET/DELETE/PUT ( supports fetch/delete/updating a link object
for the given lname)
3) v1/link/:lname/enable (action for enabling a link)
4) v1/link/:lname/disable ( action for disabling a link )
--------------------------------------
NOTE: I am using params for configs ( since config and params go hand in hand,
rather than config and inputs )
Config APIs ( might need some more thinking, open to suggestions)
ctype can be mainly 3 of them ( from, to, driver )
1) v1/config/:cftype/link/:lname - GET ( will fetch all the config params/
inputs for this link)
2) v1/config/:cftype/link/:lname - POST will create the from/to config for this
link
3) v1/config/driver/ POSTand GET ( version can be part of the driver config )
Note : We will also support creating driver configs per job Id and connector Id
if need be ( they will be POST data )
4) v1/config/:cfName ( DELETE/UPDATE/GET) for any config object.
-----------------------------------------
Job APIs
1) v1/job POST ( it will provide the fromConfig/toConfig/driverConfig map ) to
create a job
Note: driverConfig is not required, it is optional. If not given we will use
the default driver config created as part of the Sqoop system
2) v1/job/:jname - DELETE/UPDATE/GET
3) v1/job/:jname/from - GET only the from config info for this job
4) v1/job/:jname/to - GET only the to config info for this job
5) v1/job/:jname/driver - GET only the driver config info for this job if it
exists
6) v1/job/:jname/enable
7) v1/job/:jname/disable
8) v1/job/:jname/submit ( the most important one !!)
---------------------------------------------------
Submissions APIs ( read only)
1) v1/job/:jname/submissions - GET ( gets all the submissions)
2) v1/submission/:sname - GET a submission with the sname ( I hope there is a
submission Id/ name we support)
> Sqoop2: Sqoop2 Rest API refactoring
> -----------------------------------
>
> Key: SQOOP-1509
> URL: https://issues.apache.org/jira/browse/SQOOP-1509
> Project: Sqoop
> Issue Type: Improvement
> Reporter: Veena Basavaraj
> Assignee: Veena Basavaraj
>
> See the attached DOC that explains the Rest APIs for the Sqoop entities
> ------------------------------------
> Connector APIs ( read only)
> 1 ) v1/connectors - GET ( lists all connectors)
> 2 ) v1/connector/:cname - GET (fetch a connector identified by cname)
> 3) v1/connector/:cname/links - GET ( get all links associated with connector
> cname)
> -----------------------------------
> Link APIs
> We create a link per connector. Hence the api list the parent/child
> relationship.
> 1) v1/connector/:cname/link GET - gets the params list required for this
> link object ( used in the context of UI )
> 2_ v1/connector/:cname/link POST - creates a link for the connector ( since
> we have the connector name we can show the correct inputs/params for this
> link to be filled in)
> 3) v1/link/:lname GET/DELETE/PUT ( supports fetch/delete/updating a link
> object for the given lname)
> 4) v1/link/:lname/enable (action for enabling a link)
> 5) v1/link/:lname/disable ( action for disabling a link )
> --------------------------------------
> NOTE: I am using params for configs ( since config and params go hand in
> hand, rather than config and inputs )
> Config APIs ( might need some more thinking, open to suggestions)
> ctype can be mainly 3 of them ( from, to, driver )
> 1) v1/config/:cftype/link/:lname - GET ( will fetch all the config params/
> inputs for this link)
> 2) v1/config/:cftype/link/:lname - POST will create the from/to config for
> this link
> 3) v1/config/driver/ POSTand GET ( version can be part of the driver config )
> Note : We will also support creating driver configs per job Id and connector
> Id if need be ( they will be POST data )
> 4) v1/config/:cfName ( DELETE/UPDATE/GET) for any config object.
> -----------------------------------------
> Job APIs
> 1) v1/job POST ( it will provide the fromConfig/toConfig/driverConfig map )
> to create a job
> Note: driverConfig is not required, it is optional. If not given we will use
> the default driver config created as part of the Sqoop system
> 2) v1/job/:jname - DELETE/UPDATE/GET
> 3) v1/job/:jname/from - GET only the from config info for this job
> 4) v1/job/:jname/to - GET only the to config info for this job
> 5) v1/job/:jname/driver - GET only the driver config info for this job if it
> exists
> 6) v1/job/:jname/enable
> 7) v1/job/:jname/disable
> 8) v1/job/:jname/start ( the most important one !!)
> 9) v1/job/:jname/stop
> ---------------------------------------------------
> Submissions APIs ( read only)
> 1) v1/job/:jname/submissions - GET ( gets all the submissions)
> 2) v1/submission/:sname - GET a submission with the sname ( I hope there is a
> submission Id/ name we support)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
