Get targets for a collection
⚠️ DEPRECATED - This endpoint is deprecated and will be removed at the end of December 2026.
Note: Responses include a Sunset HTTP header (RFC 8594) indicating the removal date.
Migration Required
This endpoint has been replaced by the v1 Collections API. Please migrate to the new endpoint:
Replacement Endpoint
| Old Endpoint | New Endpoint | Purpose |
|---|---|---|
| GET /public/v2/network/{collectionId}/targets | GET /public/v1/collections/{collectionId}/targets | Get targets in a collection |
Why Migrate?
The v1 Collections API provides better consistency and alignment with the rest of the Collections API:
1. Consistent API Structure
- v2: Uses /public/v2/network/{collectionId}/targets which mixes network and collection concepts
- v1: Uses /public/v1/collections/{collectionId}/targets which is more intuitive and consistent with other collection endpoints
2. Better API Organization
- The v1 endpoint is part of the dedicated Collections API (PublicTargetCollectionController)
- Better aligns with RESTful principles where collection-related operations are grouped together
- More discoverable alongside other collection management endpoints
3. Enhanced Functionality
- The v1 Collections API provides additional endpoints for managing targets in collections:
- POST /public/v1/collections/{collectionId}/targets - Add targets to a collection
- DELETE /public/v1/collections/{collectionId}/targets/{targetId} - Remove a target from a collection
- GET /public/v1/collections/{collectionId}/targets - List targets in a collection (replacement)
4. Improved Documentation
- Comprehensive examples for all endpoints
- Detailed error response documentation
- Clear parameter descriptions
- Better Swagger/OpenAPI documentation
Quick Migration Guide
Step 1: Update Endpoint URL
Before:
GET /public/v2/network/{collectionId}/targets?page=0&size=20
After:
GET /public/v1/collections/{collectionId}/targets?page=0&size=20
Step 2: Verify Response Structure
The response structure is identical - no changes needed to your response parsing logic:
Response Format (unchanged):
{
"content": [
{
"id": 10422185,
"name": "Inter Cars SA"
},
{
"id": 101641243,
"name": "Asmet Sp. z o.o."
}
],
"size": 10,
"number": 0,
"totalElements": 57,
"totalPages": 6,
"numberOfElements": 2
}
Step 3: Update Error Handling
Error responses remain the same:
- 401 - Authentication required
- 403 - Insufficient permissions to read this collection
- 404 - Collection not found or not accessible to the user
Breaking Changes
None - This is a straightforward URL change with identical functionality:
- URL Path Only: Only the URL path changes from /public/v2/network/{collectionId}/targets to /public/v1/collections/{collectionId}/targets
- Response Structure: Identical - returns Page<PublicTargetRef> with id and name fields
- Query Parameters: Identical - supports standard Spring pagination parameters (page, size, sort)
- Permissions: Identical - requires ACCESS_PUBLIC_TARGET authority and READ permission on the collection
- Performance: Identical - uses the same underlying service method
Migration Example
Before (v2)
GET /public/v2/network/123/targets?page=0&size=20
After (v1)
GET /public/v1/collections/123/targets?page=0&size=20
The response will be identical in both cases.
Required Permissions: ACCESS_PUBLIC_TARGET and READ on the collection
Performance Impact: Low
For detailed API reference, see the v1 Collections API documentation.
Path parameters
Query parameters
Response
OK