use of IItemRestService vs item specific RestService

Sachin Patel (101●2●3) | asked Jul 30 '07, 1:35 p.m.
JAZZ DEVELOPER

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

4 answers

Most liked answers|Newest answers ↑|Oldest answers

permanent link

Peter Klenk (46) | answered Jul 31 '07, 11:47 a.m.
JAZZ DEVELOPER

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

permanent link

Sachin Patel (101●2●3) | answered Jul 30 '07, 3:15 p.m.
JAZZ DEVELOPER

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

permanent link

Sachin Patel (101●2●3) | answered Jul 30 '07, 2:52 p.m.
JAZZ DEVELOPER

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

permanent link

Peter Klenk (46) | answered Jul 30 '07, 2:32 p.m.
JAZZ DEVELOPER

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

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.

It's all about the answers!

Related questions

use of IItemRestService vs item specific RestService

4 answers

Your answer