How can I successfully query the Content Service using its v4 odata endpoint?

Clash Royale CLAN TAG#URR8PPP

up vote
4
down vote

favorite

I am trying to query the v4 endpoint of the odata content service with no luck. The reason I want to use that endpoint is because odata's v4 has more "filtering" options and more advanced querying functions. However unless I query for metadata or to see the entities:

I get different exceptions, for example using POSTMAN:

I've also tried using the "automatically generated proxies" (which work when generated against the v2 endpoint) and I get this error too:

DataServiceClientException: "error":"code":"1800","message":"This
query is not supported:
http://service-url-goes-here:8081/client/v4/content.svc/ComponentPresentations?$top=1"

I've spent a good full day trying serveral things, and I am starting to think that either the v4 endpoint is not ready for use or that I might have the content service not properly configured to use such endpoint.

Any pointers would be highly appreciated.

UPDATE
I decided to switch to CIL, instead of doing my thing. However when using the API I get the following exception:
Invalid v4 service endpoint for content-service

Which tells me that I was kinda right with the assumption that my v4 endpoint (or the content service all along) might not be properly configured.
I went over the documentation over and over and checked my discovery service, which has the content service properly configured pointing to the right server.
I added the configuration settings in my web.config with the oauth properties and the discovery service uri:

content-delivery web8.5 odata content-service

share|improve this question

edited Aug 14 at 16:47

asked Aug 14 at 13:13

Jaime Santos Alcón

2,836715

add a comment | 

up vote
4
down vote

favorite

I am trying to query the v4 endpoint of the odata content service with no luck. The reason I want to use that endpoint is because odata's v4 has more "filtering" options and more advanced querying functions. However unless I query for metadata or to see the entities:

I get different exceptions, for example using POSTMAN:

I've also tried using the "automatically generated proxies" (which work when generated against the v2 endpoint) and I get this error too:

DataServiceClientException: "error":"code":"1800","message":"This
query is not supported:
http://service-url-goes-here:8081/client/v4/content.svc/ComponentPresentations?$top=1"

I've spent a good full day trying serveral things, and I am starting to think that either the v4 endpoint is not ready for use or that I might have the content service not properly configured to use such endpoint.

Any pointers would be highly appreciated.

UPDATE
I decided to switch to CIL, instead of doing my thing. However when using the API I get the following exception:
Invalid v4 service endpoint for content-service

Which tells me that I was kinda right with the assumption that my v4 endpoint (or the content service all along) might not be properly configured.
I went over the documentation over and over and checked my discovery service, which has the content service properly configured pointing to the right server.
I added the configuration settings in my web.config with the oauth properties and the discovery service uri:

content-delivery web8.5 odata content-service

share|improve this question

edited Aug 14 at 16:47

asked Aug 14 at 13:13

Jaime Santos Alcón

2,836715

add a comment | 

up vote
4
down vote

favorite

up vote
4
down vote

favorite

I am trying to query the v4 endpoint of the odata content service with no luck. The reason I want to use that endpoint is because odata's v4 has more "filtering" options and more advanced querying functions. However unless I query for metadata or to see the entities:

I get different exceptions, for example using POSTMAN:

I've also tried using the "automatically generated proxies" (which work when generated against the v2 endpoint) and I get this error too:

DataServiceClientException: "error":"code":"1800","message":"This
query is not supported:
http://service-url-goes-here:8081/client/v4/content.svc/ComponentPresentations?$top=1"

I've spent a good full day trying serveral things, and I am starting to think that either the v4 endpoint is not ready for use or that I might have the content service not properly configured to use such endpoint.

Any pointers would be highly appreciated.

UPDATE
I decided to switch to CIL, instead of doing my thing. However when using the API I get the following exception:
Invalid v4 service endpoint for content-service

Which tells me that I was kinda right with the assumption that my v4 endpoint (or the content service all along) might not be properly configured.
I went over the documentation over and over and checked my discovery service, which has the content service properly configured pointing to the right server.
I added the configuration settings in my web.config with the oauth properties and the discovery service uri:

content-delivery web8.5 odata content-service

share|improve this question

edited Aug 14 at 16:47

asked Aug 14 at 13:13

Jaime Santos Alcón

2,836715

I am trying to query the v4 endpoint of the odata content service with no luck. The reason I want to use that endpoint is because odata's v4 has more "filtering" options and more advanced querying functions. However unless I query for metadata or to see the entities:

I get different exceptions, for example using POSTMAN:

I've also tried using the "automatically generated proxies" (which work when generated against the v2 endpoint) and I get this error too:

DataServiceClientException: "error":"code":"1800","message":"This
query is not supported:
http://service-url-goes-here:8081/client/v4/content.svc/ComponentPresentations?$top=1"

I've spent a good full day trying serveral things, and I am starting to think that either the v4 endpoint is not ready for use or that I might have the content service not properly configured to use such endpoint.

Any pointers would be highly appreciated.

UPDATE
I decided to switch to CIL, instead of doing my thing. However when using the API I get the following exception:
Invalid v4 service endpoint for content-service

Which tells me that I was kinda right with the assumption that my v4 endpoint (or the content service all along) might not be properly configured.
I went over the documentation over and over and checked my discovery service, which has the content service properly configured pointing to the right server.
I added the configuration settings in my web.config with the oauth properties and the discovery service uri:

content-delivery web8.5 odata content-service

share|improve this question

edited Aug 14 at 16:47

asked Aug 14 at 13:13

Jaime Santos Alcón

2,836715

share|improve this question

share|improve this question

edited Aug 14 at 16:47

edited Aug 14 at 16:47

edited Aug 14 at 16:47

asked Aug 14 at 13:13

Jaime Santos Alcón

2,836715

asked Aug 14 at 13:13

Jaime Santos Alcón

2,836715

asked Aug 14 at 13:13

Jaime Santos Alcón

2,836715

2,836715

add a comment | 

add a comment | 

3 Answers
3

active

oldest

votes

up vote
3
down vote

So I finally figured it out... It was a combination of several things, but long story short, it had to do with my settings having the wrong encoding (assuming you had the rest of the setup correctly).

However, these are the things I tried and hope that might help others when having issues connecting to the odata v4 (or v2 for that matter), using the CIL libraries:

1. Made sure I had the right settings in my web.config


2. Made sure that those settings were not copy-pasted as I realized that the discovery service setting had some weird character encoding messing around


3. Made sure all the host names in all services were not "localhost", rather the actual host name of the server, so services could be accessed from outside the server itself.


4. Made sure the "ContentService" capability was registered in the discovery service

I also recommend that when you encounter these issues, you enable "logging" in your application web.config too.

These are my settings:

 <!-- SDL WEB Settings - Services -->
 <add key="token-service-uri" value="http://server:port/token.svc"/>
 <add key="discovery-service-uri" value="http://server:port/discovery.svc"/>
 <add key="oauth‐enabled" value="true"/>
 <add key="oauth‐client‐id" value="cduser"/>
 <add key="oauth‐client‐secret" value="CDUserP@ssw0rd"/>

 <!-- SDL WEB Settings - Logger -->
 <add key="log-level" value="DEBUG"/>
 <add key="log-output" value="c:templogssdl-core.log"/>

Nuget Packages Versions (This only applies for the versions mentioned belowç)

Make sure that the dll versions on your application are compatible, for example, I am using version 8.5.0 of the Sdl.Web.CIL package which does not work with version 5.8.4 of Microsoft.Data.Edm, Microsoft.Data.OData, etc... I had to downgrade to version 5.6.4 and although the Dependency list in nuget specifies any version >= 5.6.4 should work, that's not the case. I also downgraded the "odata" dependencies to 6.15.0 (Microsoft.Spatial, Microsoft.OData.Core, Microsoft.OData.Edm, Microsoft.OData.Client)

Hope this helps :)

share|improve this answer

answered Aug 15 at 15:17

Jaime Santos Alcón

2,836715

add a comment | 

up vote
2
down vote

I could be wrong, but I believe the v4 was never intended for public use.

share|improve this answer

answered Aug 14 at 14:36

Atila Sos

2,1971720

• 
  
  
  

  
  

  
  
  
  
  
  

  
  You are right. The CIL API uses a mix of OData V2 and V4 under the hood. The idea was to further mature the V4 endpoint before declaring it public, but it now seems that will never happen and a new GraphQL endpoint will become the public API.
  – Rick Pannekoek
  Aug 14 at 15:19
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  Ok, so I switched to CIL (because I was expecting something like v4 shouldn't be used... etc...). I get the following error: "Error": "Invalid v4 service endpoint for content-service"
  – Jaime Santos Alcón
  Aug 14 at 16:03
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  Before anything.. checking the registered capabilities on the discovery service...
  – Jaime Santos Alcón
  Aug 14 at 16:06
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  I have all these capabilities: PreviewWebServiceCapability, ContentServiceCapability, DeployerCapability, WebCapability and TOkenServiceCapability. Do I also need the ContextCapability mentioned here:tridion.stackexchange.com/questions/17760/…
  – Jaime Santos Alcón
  Aug 14 at 16:10
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  If you're getting a v4 endpoint error, it could be worth double checking that you definitely have the Discover Service URL configured correctly in your web.config. It should be something like: <add key="discovery-service-uri" value="http://localhost:8082/discovery.svc" />
  – Jonathan Williams
  Aug 14 at 20:45
  

  
  
  
  

 | 
show 3 more comments

up vote
1
down vote

I'm not sure if it's supported to directly use the v2 or v4 service endpoints. I always thought the CIL libraries know internally which service to use for a specific query.

share|improve this answer

answered Aug 14 at 13:29

Harald Hoffelinck

7,2761226

• 
  
  
  

  
  

  
  
  
  
  
  

  
  I am trying to avoid using the CIL libraries
  – Jaime Santos Alcón
  Aug 14 at 13:35
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  @Harald, v2 is supported and can be used without any issues, for v4 I'm not certain. There are some valid use cases for directly using these endpoints. The biggest disadvantage of this approach however I would say is that you have to handle the OAuth part (initial authorization, token renewal when expired, etc.) manually (if the Content Service is protected that is).
  – Atila Sos
  Aug 14 at 14:46
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  I have a class that takes care of the OAuth part... and CIL doesn't seem to be working, so I might have something not properly configured... dunno what, though
  – Jaime Santos Alcón
  Aug 14 at 16:36
  

  
  
  
  

add a comment | 

Your Answer

StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "485"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
convertImagesToLinks: false,
noModals: false,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);

 

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name Email

StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2ftridion.stackexchange.com%2fquestions%2f19212%2fhow-can-i-successfully-query-the-content-service-using-its-v4-odata-endpoint%23new-answer', 'question_page');

);

Post as a guest

Name Email

3 Answers
3

active

oldest

votes

3 Answers
3

active

oldest

votes

active

oldest

votes

active

oldest

votes

up vote
3
down vote

So I finally figured it out... It was a combination of several things, but long story short, it had to do with my settings having the wrong encoding (assuming you had the rest of the setup correctly).

However, these are the things I tried and hope that might help others when having issues connecting to the odata v4 (or v2 for that matter), using the CIL libraries:

1. Made sure I had the right settings in my web.config


2. Made sure that those settings were not copy-pasted as I realized that the discovery service setting had some weird character encoding messing around


3. Made sure all the host names in all services were not "localhost", rather the actual host name of the server, so services could be accessed from outside the server itself.


4. Made sure the "ContentService" capability was registered in the discovery service

I also recommend that when you encounter these issues, you enable "logging" in your application web.config too.

These are my settings:

 <!-- SDL WEB Settings - Services -->
 <add key="token-service-uri" value="http://server:port/token.svc"/>
 <add key="discovery-service-uri" value="http://server:port/discovery.svc"/>
 <add key="oauth‐enabled" value="true"/>
 <add key="oauth‐client‐id" value="cduser"/>
 <add key="oauth‐client‐secret" value="CDUserP@ssw0rd"/>

 <!-- SDL WEB Settings - Logger -->
 <add key="log-level" value="DEBUG"/>
 <add key="log-output" value="c:templogssdl-core.log"/>

Nuget Packages Versions (This only applies for the versions mentioned belowç)

Make sure that the dll versions on your application are compatible, for example, I am using version 8.5.0 of the Sdl.Web.CIL package which does not work with version 5.8.4 of Microsoft.Data.Edm, Microsoft.Data.OData, etc... I had to downgrade to version 5.6.4 and although the Dependency list in nuget specifies any version >= 5.6.4 should work, that's not the case. I also downgraded the "odata" dependencies to 6.15.0 (Microsoft.Spatial, Microsoft.OData.Core, Microsoft.OData.Edm, Microsoft.OData.Client)

Hope this helps :)

share|improve this answer

answered Aug 15 at 15:17

Jaime Santos Alcón

2,836715

add a comment | 

up vote
3
down vote

So I finally figured it out... It was a combination of several things, but long story short, it had to do with my settings having the wrong encoding (assuming you had the rest of the setup correctly).

However, these are the things I tried and hope that might help others when having issues connecting to the odata v4 (or v2 for that matter), using the CIL libraries:

1. Made sure I had the right settings in my web.config


2. Made sure that those settings were not copy-pasted as I realized that the discovery service setting had some weird character encoding messing around


3. Made sure all the host names in all services were not "localhost", rather the actual host name of the server, so services could be accessed from outside the server itself.


4. Made sure the "ContentService" capability was registered in the discovery service

I also recommend that when you encounter these issues, you enable "logging" in your application web.config too.

These are my settings:

 <!-- SDL WEB Settings - Services -->
 <add key="token-service-uri" value="http://server:port/token.svc"/>
 <add key="discovery-service-uri" value="http://server:port/discovery.svc"/>
 <add key="oauth‐enabled" value="true"/>
 <add key="oauth‐client‐id" value="cduser"/>
 <add key="oauth‐client‐secret" value="CDUserP@ssw0rd"/>

 <!-- SDL WEB Settings - Logger -->
 <add key="log-level" value="DEBUG"/>
 <add key="log-output" value="c:templogssdl-core.log"/>

Nuget Packages Versions (This only applies for the versions mentioned belowç)

Make sure that the dll versions on your application are compatible, for example, I am using version 8.5.0 of the Sdl.Web.CIL package which does not work with version 5.8.4 of Microsoft.Data.Edm, Microsoft.Data.OData, etc... I had to downgrade to version 5.6.4 and although the Dependency list in nuget specifies any version >= 5.6.4 should work, that's not the case. I also downgraded the "odata" dependencies to 6.15.0 (Microsoft.Spatial, Microsoft.OData.Core, Microsoft.OData.Edm, Microsoft.OData.Client)

Hope this helps :)

share|improve this answer

answered Aug 15 at 15:17

Jaime Santos Alcón

2,836715

add a comment | 

up vote
3
down vote

up vote
3
down vote

So I finally figured it out... It was a combination of several things, but long story short, it had to do with my settings having the wrong encoding (assuming you had the rest of the setup correctly).

However, these are the things I tried and hope that might help others when having issues connecting to the odata v4 (or v2 for that matter), using the CIL libraries:

1. Made sure I had the right settings in my web.config


2. Made sure that those settings were not copy-pasted as I realized that the discovery service setting had some weird character encoding messing around


3. Made sure all the host names in all services were not "localhost", rather the actual host name of the server, so services could be accessed from outside the server itself.


4. Made sure the "ContentService" capability was registered in the discovery service

I also recommend that when you encounter these issues, you enable "logging" in your application web.config too.

These are my settings:

 <!-- SDL WEB Settings - Services -->
 <add key="token-service-uri" value="http://server:port/token.svc"/>
 <add key="discovery-service-uri" value="http://server:port/discovery.svc"/>
 <add key="oauth‐enabled" value="true"/>
 <add key="oauth‐client‐id" value="cduser"/>
 <add key="oauth‐client‐secret" value="CDUserP@ssw0rd"/>

 <!-- SDL WEB Settings - Logger -->
 <add key="log-level" value="DEBUG"/>
 <add key="log-output" value="c:templogssdl-core.log"/>

Nuget Packages Versions (This only applies for the versions mentioned belowç)

Make sure that the dll versions on your application are compatible, for example, I am using version 8.5.0 of the Sdl.Web.CIL package which does not work with version 5.8.4 of Microsoft.Data.Edm, Microsoft.Data.OData, etc... I had to downgrade to version 5.6.4 and although the Dependency list in nuget specifies any version >= 5.6.4 should work, that's not the case. I also downgraded the "odata" dependencies to 6.15.0 (Microsoft.Spatial, Microsoft.OData.Core, Microsoft.OData.Edm, Microsoft.OData.Client)

Hope this helps :)

share|improve this answer

answered Aug 15 at 15:17

Jaime Santos Alcón

2,836715

So I finally figured it out... It was a combination of several things, but long story short, it had to do with my settings having the wrong encoding (assuming you had the rest of the setup correctly).

However, these are the things I tried and hope that might help others when having issues connecting to the odata v4 (or v2 for that matter), using the CIL libraries:

1. Made sure I had the right settings in my web.config


2. Made sure that those settings were not copy-pasted as I realized that the discovery service setting had some weird character encoding messing around


3. Made sure all the host names in all services were not "localhost", rather the actual host name of the server, so services could be accessed from outside the server itself.


4. Made sure the "ContentService" capability was registered in the discovery service

I also recommend that when you encounter these issues, you enable "logging" in your application web.config too.

These are my settings:

 <!-- SDL WEB Settings - Services -->
 <add key="token-service-uri" value="http://server:port/token.svc"/>
 <add key="discovery-service-uri" value="http://server:port/discovery.svc"/>
 <add key="oauth‐enabled" value="true"/>
 <add key="oauth‐client‐id" value="cduser"/>
 <add key="oauth‐client‐secret" value="CDUserP@ssw0rd"/>

 <!-- SDL WEB Settings - Logger -->
 <add key="log-level" value="DEBUG"/>
 <add key="log-output" value="c:templogssdl-core.log"/>

Nuget Packages Versions (This only applies for the versions mentioned belowç)

Make sure that the dll versions on your application are compatible, for example, I am using version 8.5.0 of the Sdl.Web.CIL package which does not work with version 5.8.4 of Microsoft.Data.Edm, Microsoft.Data.OData, etc... I had to downgrade to version 5.6.4 and although the Dependency list in nuget specifies any version >= 5.6.4 should work, that's not the case. I also downgraded the "odata" dependencies to 6.15.0 (Microsoft.Spatial, Microsoft.OData.Core, Microsoft.OData.Edm, Microsoft.OData.Client)

Hope this helps :)

share|improve this answer

answered Aug 15 at 15:17

Jaime Santos Alcón

2,836715

share|improve this answer

share|improve this answer

answered Aug 15 at 15:17

Jaime Santos Alcón

2,836715

answered Aug 15 at 15:17

Jaime Santos Alcón

2,836715

answered Aug 15 at 15:17

Jaime Santos Alcón

2,836715

2,836715

add a comment | 

add a comment | 

up vote
2
down vote

I could be wrong, but I believe the v4 was never intended for public use.

share|improve this answer

answered Aug 14 at 14:36

Atila Sos

2,1971720

• 
  
  
  

  
  

  
  
  
  
  
  

  
  You are right. The CIL API uses a mix of OData V2 and V4 under the hood. The idea was to further mature the V4 endpoint before declaring it public, but it now seems that will never happen and a new GraphQL endpoint will become the public API.
  – Rick Pannekoek
  Aug 14 at 15:19
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  Ok, so I switched to CIL (because I was expecting something like v4 shouldn't be used... etc...). I get the following error: "Error": "Invalid v4 service endpoint for content-service"
  – Jaime Santos Alcón
  Aug 14 at 16:03
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  Before anything.. checking the registered capabilities on the discovery service...
  – Jaime Santos Alcón
  Aug 14 at 16:06
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  I have all these capabilities: PreviewWebServiceCapability, ContentServiceCapability, DeployerCapability, WebCapability and TOkenServiceCapability. Do I also need the ContextCapability mentioned here:tridion.stackexchange.com/questions/17760/…
  – Jaime Santos Alcón
  Aug 14 at 16:10
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  If you're getting a v4 endpoint error, it could be worth double checking that you definitely have the Discover Service URL configured correctly in your web.config. It should be something like: <add key="discovery-service-uri" value="http://localhost:8082/discovery.svc" />
  – Jonathan Williams
  Aug 14 at 20:45
  

  
  
  
  

 | 
show 3 more comments

up vote
2
down vote

I could be wrong, but I believe the v4 was never intended for public use.

share|improve this answer

answered Aug 14 at 14:36

Atila Sos

2,1971720

• 
  
  
  

  
  

  
  
  
  
  
  

  
  You are right. The CIL API uses a mix of OData V2 and V4 under the hood. The idea was to further mature the V4 endpoint before declaring it public, but it now seems that will never happen and a new GraphQL endpoint will become the public API.
  – Rick Pannekoek
  Aug 14 at 15:19
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  Ok, so I switched to CIL (because I was expecting something like v4 shouldn't be used... etc...). I get the following error: "Error": "Invalid v4 service endpoint for content-service"
  – Jaime Santos Alcón
  Aug 14 at 16:03
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  Before anything.. checking the registered capabilities on the discovery service...
  – Jaime Santos Alcón
  Aug 14 at 16:06
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  I have all these capabilities: PreviewWebServiceCapability, ContentServiceCapability, DeployerCapability, WebCapability and TOkenServiceCapability. Do I also need the ContextCapability mentioned here:tridion.stackexchange.com/questions/17760/…
  – Jaime Santos Alcón
  Aug 14 at 16:10
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  If you're getting a v4 endpoint error, it could be worth double checking that you definitely have the Discover Service URL configured correctly in your web.config. It should be something like: <add key="discovery-service-uri" value="http://localhost:8082/discovery.svc" />
  – Jonathan Williams
  Aug 14 at 20:45
  

  
  
  
  

 | 
show 3 more comments

up vote
2
down vote

up vote
2
down vote

I could be wrong, but I believe the v4 was never intended for public use.

share|improve this answer

answered Aug 14 at 14:36

Atila Sos

2,1971720

I could be wrong, but I believe the v4 was never intended for public use.

share|improve this answer

answered Aug 14 at 14:36

Atila Sos

2,1971720

share|improve this answer

share|improve this answer

answered Aug 14 at 14:36

Atila Sos

2,1971720

answered Aug 14 at 14:36

Atila Sos

2,1971720

answered Aug 14 at 14:36

Atila Sos

2,1971720

2,1971720

• 
  
  
  

  
  

  
  
  
  
  
  

  
  You are right. The CIL API uses a mix of OData V2 and V4 under the hood. The idea was to further mature the V4 endpoint before declaring it public, but it now seems that will never happen and a new GraphQL endpoint will become the public API.
  – Rick Pannekoek
  Aug 14 at 15:19
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  Ok, so I switched to CIL (because I was expecting something like v4 shouldn't be used... etc...). I get the following error: "Error": "Invalid v4 service endpoint for content-service"
  – Jaime Santos Alcón
  Aug 14 at 16:03
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  Before anything.. checking the registered capabilities on the discovery service...
  – Jaime Santos Alcón
  Aug 14 at 16:06
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  I have all these capabilities: PreviewWebServiceCapability, ContentServiceCapability, DeployerCapability, WebCapability and TOkenServiceCapability. Do I also need the ContextCapability mentioned here:tridion.stackexchange.com/questions/17760/…
  – Jaime Santos Alcón
  Aug 14 at 16:10
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  If you're getting a v4 endpoint error, it could be worth double checking that you definitely have the Discover Service URL configured correctly in your web.config. It should be something like: <add key="discovery-service-uri" value="http://localhost:8082/discovery.svc" />
  – Jonathan Williams
  Aug 14 at 20:45
  

  
  
  
  

 | 
show 3 more comments

• 
  
  
  

  
  

  
  
  
  
  
  

  
  You are right. The CIL API uses a mix of OData V2 and V4 under the hood. The idea was to further mature the V4 endpoint before declaring it public, but it now seems that will never happen and a new GraphQL endpoint will become the public API.
  – Rick Pannekoek
  Aug 14 at 15:19
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  Ok, so I switched to CIL (because I was expecting something like v4 shouldn't be used... etc...). I get the following error: "Error": "Invalid v4 service endpoint for content-service"
  – Jaime Santos Alcón
  Aug 14 at 16:03
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  Before anything.. checking the registered capabilities on the discovery service...
  – Jaime Santos Alcón
  Aug 14 at 16:06
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  I have all these capabilities: PreviewWebServiceCapability, ContentServiceCapability, DeployerCapability, WebCapability and TOkenServiceCapability. Do I also need the ContextCapability mentioned here:tridion.stackexchange.com/questions/17760/…
  – Jaime Santos Alcón
  Aug 14 at 16:10
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  If you're getting a v4 endpoint error, it could be worth double checking that you definitely have the Discover Service URL configured correctly in your web.config. It should be something like: <add key="discovery-service-uri" value="http://localhost:8082/discovery.svc" />
  – Jonathan Williams
  Aug 14 at 20:45
  

  
  
  
  

You are right. The CIL API uses a mix of OData V2 and V4 under the hood. The idea was to further mature the V4 endpoint before declaring it public, but it now seems that will never happen and a new GraphQL endpoint will become the public API.
– Rick Pannekoek
Aug 14 at 15:19

You are right. The CIL API uses a mix of OData V2 and V4 under the hood. The idea was to further mature the V4 endpoint before declaring it public, but it now seems that will never happen and a new GraphQL endpoint will become the public API.
– Rick Pannekoek
Aug 14 at 15:19

Ok, so I switched to CIL (because I was expecting something like v4 shouldn't be used... etc...). I get the following error: "Error": "Invalid v4 service endpoint for content-service"
– Jaime Santos Alcón
Aug 14 at 16:03

Ok, so I switched to CIL (because I was expecting something like v4 shouldn't be used... etc...). I get the following error: "Error": "Invalid v4 service endpoint for content-service"
– Jaime Santos Alcón
Aug 14 at 16:03

Before anything.. checking the registered capabilities on the discovery service...
– Jaime Santos Alcón
Aug 14 at 16:06

Before anything.. checking the registered capabilities on the discovery service...
– Jaime Santos Alcón
Aug 14 at 16:06

I have all these capabilities: PreviewWebServiceCapability, ContentServiceCapability, DeployerCapability, WebCapability and TOkenServiceCapability. Do I also need the ContextCapability mentioned here:tridion.stackexchange.com/questions/17760/…
– Jaime Santos Alcón
Aug 14 at 16:10

I have all these capabilities: PreviewWebServiceCapability, ContentServiceCapability, DeployerCapability, WebCapability and TOkenServiceCapability. Do I also need the ContextCapability mentioned here:tridion.stackexchange.com/questions/17760/…
– Jaime Santos Alcón
Aug 14 at 16:10

If you're getting a v4 endpoint error, it could be worth double checking that you definitely have the Discover Service URL configured correctly in your web.config. It should be something like: <add key="discovery-service-uri" value="http://localhost:8082/discovery.svc" />
– Jonathan Williams
Aug 14 at 20:45

If you're getting a v4 endpoint error, it could be worth double checking that you definitely have the Discover Service URL configured correctly in your web.config. It should be something like: <add key="discovery-service-uri" value="http://localhost:8082/discovery.svc" />
– Jonathan Williams
Aug 14 at 20:45

 | 
show 3 more comments

up vote
1
down vote

I'm not sure if it's supported to directly use the v2 or v4 service endpoints. I always thought the CIL libraries know internally which service to use for a specific query.

share|improve this answer

answered Aug 14 at 13:29

Harald Hoffelinck

7,2761226

• 
  
  
  

  
  

  
  
  
  
  
  

  
  I am trying to avoid using the CIL libraries
  – Jaime Santos Alcón
  Aug 14 at 13:35
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  @Harald, v2 is supported and can be used without any issues, for v4 I'm not certain. There are some valid use cases for directly using these endpoints. The biggest disadvantage of this approach however I would say is that you have to handle the OAuth part (initial authorization, token renewal when expired, etc.) manually (if the Content Service is protected that is).
  – Atila Sos
  Aug 14 at 14:46
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  I have a class that takes care of the OAuth part... and CIL doesn't seem to be working, so I might have something not properly configured... dunno what, though
  – Jaime Santos Alcón
  Aug 14 at 16:36
  

  
  
  
  

add a comment | 

up vote
1
down vote

I'm not sure if it's supported to directly use the v2 or v4 service endpoints. I always thought the CIL libraries know internally which service to use for a specific query.

share|improve this answer

answered Aug 14 at 13:29

Harald Hoffelinck

7,2761226

• 
  
  
  

  
  

  
  
  
  
  
  

  
  I am trying to avoid using the CIL libraries
  – Jaime Santos Alcón
  Aug 14 at 13:35
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  @Harald, v2 is supported and can be used without any issues, for v4 I'm not certain. There are some valid use cases for directly using these endpoints. The biggest disadvantage of this approach however I would say is that you have to handle the OAuth part (initial authorization, token renewal when expired, etc.) manually (if the Content Service is protected that is).
  – Atila Sos
  Aug 14 at 14:46
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  I have a class that takes care of the OAuth part... and CIL doesn't seem to be working, so I might have something not properly configured... dunno what, though
  – Jaime Santos Alcón
  Aug 14 at 16:36
  

  
  
  
  

add a comment | 

up vote
1
down vote

up vote
1
down vote

I'm not sure if it's supported to directly use the v2 or v4 service endpoints. I always thought the CIL libraries know internally which service to use for a specific query.

share|improve this answer

answered Aug 14 at 13:29

Harald Hoffelinck

7,2761226

I'm not sure if it's supported to directly use the v2 or v4 service endpoints. I always thought the CIL libraries know internally which service to use for a specific query.

share|improve this answer

answered Aug 14 at 13:29

Harald Hoffelinck

7,2761226

share|improve this answer

share|improve this answer

answered Aug 14 at 13:29

Harald Hoffelinck

7,2761226

answered Aug 14 at 13:29

Harald Hoffelinck

7,2761226

answered Aug 14 at 13:29

Harald Hoffelinck

7,2761226

7,2761226

• 
  
  
  

  
  

  
  
  
  
  
  

  
  I am trying to avoid using the CIL libraries
  – Jaime Santos Alcón
  Aug 14 at 13:35
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  @Harald, v2 is supported and can be used without any issues, for v4 I'm not certain. There are some valid use cases for directly using these endpoints. The biggest disadvantage of this approach however I would say is that you have to handle the OAuth part (initial authorization, token renewal when expired, etc.) manually (if the Content Service is protected that is).
  – Atila Sos
  Aug 14 at 14:46
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  I have a class that takes care of the OAuth part... and CIL doesn't seem to be working, so I might have something not properly configured... dunno what, though
  – Jaime Santos Alcón
  Aug 14 at 16:36
  

  
  
  
  

add a comment | 

• 
  
  
  

  
  

  
  
  
  
  
  

  
  I am trying to avoid using the CIL libraries
  – Jaime Santos Alcón
  Aug 14 at 13:35
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  @Harald, v2 is supported and can be used without any issues, for v4 I'm not certain. There are some valid use cases for directly using these endpoints. The biggest disadvantage of this approach however I would say is that you have to handle the OAuth part (initial authorization, token renewal when expired, etc.) manually (if the Content Service is protected that is).
  – Atila Sos
  Aug 14 at 14:46
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  I have a class that takes care of the OAuth part... and CIL doesn't seem to be working, so I might have something not properly configured... dunno what, though
  – Jaime Santos Alcón
  Aug 14 at 16:36
  

  
  
  
  

I am trying to avoid using the CIL libraries
– Jaime Santos Alcón
Aug 14 at 13:35

I am trying to avoid using the CIL libraries
– Jaime Santos Alcón
Aug 14 at 13:35

@Harald, v2 is supported and can be used without any issues, for v4 I'm not certain. There are some valid use cases for directly using these endpoints. The biggest disadvantage of this approach however I would say is that you have to handle the OAuth part (initial authorization, token renewal when expired, etc.) manually (if the Content Service is protected that is).
– Atila Sos
Aug 14 at 14:46

@Harald, v2 is supported and can be used without any issues, for v4 I'm not certain. There are some valid use cases for directly using these endpoints. The biggest disadvantage of this approach however I would say is that you have to handle the OAuth part (initial authorization, token renewal when expired, etc.) manually (if the Content Service is protected that is).
– Atila Sos
Aug 14 at 14:46

I have a class that takes care of the OAuth part... and CIL doesn't seem to be working, so I might have something not properly configured... dunno what, though
– Jaime Santos Alcón
Aug 14 at 16:36

I have a class that takes care of the OAuth part... and CIL doesn't seem to be working, so I might have something not properly configured... dunno what, though
– Jaime Santos Alcón
Aug 14 at 16:36

add a comment | 

 

draft saved

draft discarded

 

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name Email

StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2ftridion.stackexchange.com%2fquestions%2f19212%2fhow-can-i-successfully-query-the-content-service-using-its-v4-odata-endpoint%23new-answer', 'question_page');

);

Post as a guest

Name Email

Sign up or log in

StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name Email

Sign up or log in

StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name Email

Sign up or log in

StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name Email

Name Email

Name

Email

Name Email

Name

Email