Jazz Forum Welcome to the Jazz Community Forum Connect and collaborate with IBM Engineering experts and users

use of IItemRestService vs item specific RestService

Is IItemRestService a generic service that can be used to construct,
modify, and retrieve any artifact in our component model? If so, I'm a
little confused whether or not its even necessary for us to create our
own rest service methods that do basic retrieval and creation of Items
in our model. Is there a distinct separation of roles that the
IItemRestService plays as apposed to a specific item's rest service?
When would one be used over the other?

It looks like the IItemRestService is can be used to construct new
items, and retrive complete collection of items, but not capable of
doing any querying with a specific set of attributes. In which case,
the necessary methods with the supported params would need to be
supplied to the item's rest service. Is this a correct assumtion?

If the IItemRestService can be used to construct and modify items in the
repo, why are the post* methods in many of the modeled rest services
even necessary?

The example's I'm looking at are IContributorRestService and the tests
in ContributorItemRestTests. It seems as if
IContributorRestService.postContributor could be achived by going
through IItemRestService.

Can anyone help clear up my confusion?

Thanks,

- Sachin

0 votes



4 answers

Permanent link
The IItemRestService framework is relatively new, and is intended to be a
general framework for creating, reading, updating, and deleting items. All
items are addressable with URIs managed by the Location class. Components
must implement the ICrudService RPC interface and register their
implementation with the com.ibm.team.repository.service.crudService
extension point in order for the components' items to be available through
the IItemRestService.

ICrudService has variants of the read, create, and update methods that pass
query parameters from the request URI to the component implementation, which
may address your query needs.

Many of the other REST services, including IContributorRestService, were
implemented in an older REST framework (ITeamModelledRestService) to support
the WebUI. They won't go away anytime soon, but I suggest new components
start with the IItemRestService framework.

BTW, work items related to the REST framework are assigned to the
"Repository Gateway" component. Two of the areas we hope to look at in M3
are (1) defining a resource representation independent from the item's ecore
model, and (2) expanding the framework to expose resources that are not
items, e.g. resources that are the result of or input to server-side
computations.

-- Peter

"Sachin Patel" <sppatel@us.ibm.com> wrote in message
news:f8l7g3$f8a$1@localhost.localdomain...
Is IItemRestService a generic service that can be used to construct,
modify, and retrieve any artifact in our component model? If so, I'm a
little confused whether or not its even necessary for us to create our own
rest service methods that do basic retrieval and creation of Items in our
model. Is there a distinct separation of roles that the IItemRestService
plays as apposed to a specific item's rest service? When would one be used
over the other?

It looks like the IItemRestService is can be used to construct new items,
and retrive complete collection of items, but not capable of doing any
querying with a specific set of attributes. In which case, the necessary
methods with the supported params would need to be supplied to the item's
rest service. Is this a correct assumtion?

If the IItemRestService can be used to construct and modify items in the
repo, why are the post* methods in many of the modeled rest services even
necessary?

The example's I'm looking at are IContributorRestService and the tests in
ContributorItemRestTests. It seems as if
IContributorRestService.postContributor could be achived by going through
IItemRestService.

Can anyone help clear up my confusion?

Thanks,

- Sachin

0 votes


Permanent link
Thanks for the explanation, I knew there work being done for a new
service mechanism but didn't realize IItemRestService was related to it.

Since you're recommending to start using ICrudService, are there usage
examples that you can point me to for reference?

Thanks.

Peter Klenk wrote:
The IItemRestService framework is relatively new, and is intended to be a
general framework for creating, reading, updating, and deleting items. All
items are addressable with URIs managed by the Location class. Components
must implement the ICrudService RPC interface and register their
implementation with the com.ibm.team.repository.service.crudService
extension point in order for the components' items to be available through
the IItemRestService.

ICrudService has variants of the read, create, and update methods that pass
query parameters from the request URI to the component implementation, which
may address your query needs.

Many of the other REST services, including IContributorRestService, were
implemented in an older REST framework (ITeamModelledRestService) to support
the WebUI. They won't go away anytime soon, but I suggest new components
start with the IItemRestService framework.

BTW, work items related to the REST framework are assigned to the
"Repository Gateway" component. Two of the areas we hope to look at in M3
are (1) defining a resource representation independent from the item's ecore
model, and (2) expanding the framework to expose resources that are not
items, e.g. resources that are the result of or input to server-side
computations.

-- Peter

"Sachin Patel" <sppatel@us.ibm.com> wrote in message
news:f8l7g3$f8a$1@localhost.localdomain...
Is IItemRestService a generic service that can be used to construct,
modify, and retrieve any artifact in our component model? If so, I'm a
little confused whether or not its even necessary for us to create our own
rest service methods that do basic retrieval and creation of Items in our
model. Is there a distinct separation of roles that the IItemRestService
plays as apposed to a specific item's rest service? When would one be used
over the other?

It looks like the IItemRestService is can be used to construct new items,
and retrive complete collection of items, but not capable of doing any
querying with a specific set of attributes. In which case, the necessary
methods with the supported params would need to be supplied to the item's
rest service. Is this a correct assumtion?

If the IItemRestService can be used to construct and modify items in the
repo, why are the post* methods in many of the modeled rest services even
necessary?

The example's I'm looking at are IContributorRestService and the tests in
ContributorItemRestTests. It seems as if
IContributorRestService.postContributor could be achived by going through
IItemRestService.

Can anyone help clear up my confusion?

Thanks,

- Sachin

0 votes


Permanent link
Hi Peter,

Also could you expand on or point me to more info on the 2 new features
in M3 you refer to at the end. This sounds interesting.

- Sachin

Peter Klenk wrote:
The IItemRestService framework is relatively new, and is intended to be a
general framework for creating, reading, updating, and deleting items. All
items are addressable with URIs managed by the Location class. Components
must implement the ICrudService RPC interface and register their
implementation with the com.ibm.team.repository.service.crudService
extension point in order for the components' items to be available through
the IItemRestService.

ICrudService has variants of the read, create, and update methods that pass
query parameters from the request URI to the component implementation, which
may address your query needs.

Many of the other REST services, including IContributorRestService, were
implemented in an older REST framework (ITeamModelledRestService) to support
the WebUI. They won't go away anytime soon, but I suggest new components
start with the IItemRestService framework.

BTW, work items related to the REST framework are assigned to the
"Repository Gateway" component. Two of the areas we hope to look at in M3
are (1) defining a resource representation independent from the item's ecore
model, and (2) expanding the framework to expose resources that are not
items, e.g. resources that are the result of or input to server-side
computations.

-- Peter

"Sachin Patel" <sppatel@us.ibm.com> wrote in message
news:f8l7g3$f8a$1@localhost.localdomain...
Is IItemRestService a generic service that can be used to construct,
modify, and retrieve any artifact in our component model? If so, I'm a
little confused whether or not its even necessary for us to create our own
rest service methods that do basic retrieval and creation of Items in our
model. Is there a distinct separation of roles that the IItemRestService
plays as apposed to a specific item's rest service? When would one be used
over the other?

It looks like the IItemRestService is can be used to construct new items,
and retrive complete collection of items, but not capable of doing any
querying with a specific set of attributes. In which case, the necessary
methods with the supported params would need to be supplied to the item's
rest service. Is this a correct assumtion?

If the IItemRestService can be used to construct and modify items in the
repo, why are the post* methods in many of the modeled rest services even
necessary?

The example's I'm looking at are IContributorRestService and the tests in
ContributorItemRestTests. It seems as if
IContributorRestService.postContributor could be achived by going through
IItemRestService.

Can anyone help clear up my confusion?

Thanks,

- Sachin

0 votes


Permanent link
There are currently two implementations of ICrudService, one for the
repository component and one for the interop component (each component
registers one implementation that may than fan out internally based on item
type). I don't think these are in build I20070711-2021, so you'll need to
wait for the next one.

We don't have any published client code. One use is in the ClearQuest
connectors to Jazz -- ClearQuest uses the REST service to send data into
Jazz.

-- Peter

"Sachin Patel" <sppatel@us.ibm.com> wrote in message
news:f8lc1t$hc9$1@localhost.localdomain...
Thanks for the explanation, I knew there work being done for a new service
mechanism but didn't realize IItemRestService was related to it.

Since you're recommending to start using ICrudService, are there usage
examples that you can point me to for reference?

Thanks.

Peter Klenk wrote:
The IItemRestService framework is relatively new, and is intended to be a
general framework for creating, reading, updating, and deleting items.
All items are addressable with URIs managed by the Location class.
Components must implement the ICrudService RPC interface and register
their implementation with the com.ibm.team.repository.service.crudService
extension point in order for the components' items to be available
through the IItemRestService.

ICrudService has variants of the read, create, and update methods that
pass query parameters from the request URI to the component
implementation, which may address your query needs.

Many of the other REST services, including IContributorRestService, were
implemented in an older REST framework (ITeamModelledRestService) to
support the WebUI. They won't go away anytime soon, but I suggest new
components start with the IItemRestService framework.

BTW, work items related to the REST framework are assigned to the
"Repository Gateway" component. Two of the areas we hope to look at in M3
are (1) defining a resource representation independent from the item's
ecore model, and (2) expanding the framework to expose resources that are
not items, e.g. resources that are the result of or input to server-side
computations.

-- Peter

"Sachin Patel" <sppatel@us.ibm.com> wrote in message
news:f8l7g3$f8a$1@localhost.localdomain...
Is IItemRestService a generic service that can be used to construct,
modify, and retrieve any artifact in our component model? If so, I'm a
little confused whether or not its even necessary for us to create our
own rest service methods that do basic retrieval and creation of Items
in our model. Is there a distinct separation of roles that the
IItemRestService plays as apposed to a specific item's rest service?
When would one be used over the other?

It looks like the IItemRestService is can be used to construct new
items, and retrive complete collection of items, but not capable of
doing any querying with a specific set of attributes. In which case,
the necessary methods with the supported params would need to be
supplied to the item's rest service. Is this a correct assumtion?

If the IItemRestService can be used to construct and modify items in the
repo, why are the post* methods in many of the modeled rest services
even necessary?

The example's I'm looking at are IContributorRestService and the tests
in ContributorItemRestTests. It seems as if
IContributorRestService.postContributor could be achived by going
through IItemRestService.

Can anyone help clear up my confusion?

Thanks,

- Sachin

0 votes

Your answer

Register or log in to post your answer.

Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.

Search context
Follow this question

By Email: 

Once you sign in you will be able to subscribe for any updates here.

By RSS:

Answers
Answers and Comments
Question details
× 10,952

Question asked: Jul 30 '07, 1:35 p.m.

Question was seen: 8,675 times

Last updated: Jul 30 '07, 1:35 p.m.

Confirmation Cancel Confirm