A Custom object is not visible to the API (using WWW::SalesForce Perl Module), but IS visible using the debug console.
When I say "not visible", it is not queriable, and does not appear in the list returned to the
$sf->describeGlobal();
command.
The object has all related API attributes checked off. Has anyone else had this experience and been able to resolve?
The perl module you mention is pretty old and based on an old API version, your custom object is likely using a feature which makes it incompatible with older api versions, and so won't appear in them. You could possibly update the module to a newer API version (or see if it has a property to indicate which salesforce API version to use), or switch to something else, I'd imagine that calling the Salesforce REST/JSON API from Perl ought to be pretty straightforward.
Related
I am using Rest Doc to document my Rest APIs. Based on the TestNg methods I generate the snippets that, later on, I use in the asciidoc.
For example, I have a rest endpoint to retrieve people, and also the TestNg method to document it. So then, I can use it in my ascii doc like this:
=== Get People
Get the people registered.
operation::get-people[snippets='http-request,request-fields,http-response,response-fields,error-codes']
But now, my API changed, and I introduced versioning, so the API is different from version 1 to version 2. I also want to document that properly, but I don't know how to do it by being the "less intrusive" possible.
I would like my documentation to have this structure
Resources
v1
getPeople
v2
getPeople
For the API that really change from one version to another I need to generate a different snippet per version the api support, since maybe the request fields or response fields are different.
But, I also have some other rest endpoints that has the same API from one version to another, and I think that I also need to generate the snippets for each version since the version is part of the rest endpoint path.
Do you have any idea on how to being able to add versioning to the rest docs?
Using the latest Service Fabric SDK, we would like to replace the restrictive DataContractSerializer with a custom IStateSerializer that uses JSON serialization. We have found the IReliableStateManager.TryAddStateSerializer method, however it is marked as obsolete.
How else can we register a custom IStateSerializer?
There's no alternative way. Using it in this way is supported, but the way it works will change somewhere in the future. You should make the call based on whether you're prepared to deal with that uncertainty.
I'm doing a Java Backed Webscript to put in Alfresco and call it via REST. This Webscript must do a set of 3 operations (find a path, create a folder and upload a document).
I read about this and found similar examples to do this operations throw the native Alfresco API, with methods like getFileFolderService, getContentService, etc. of Repository or ServiceRegistry classes. All in Java, without javascript.
But I would rather use REST calls instead of Alfresco API inside my Webscript. I think that if already exists Webscripts to do these operacions, is easier call them than use Alfresco API methods to try to do it. And if the API changes in future versions, the REST calls would remain the same. But I'm new here and I don't know if I'm wrong.
In summary: to do these 3 operacions, one after another, in my backed webscript, what is better and why? Use native API methods or use REST calls to existing webscripts?
And if I try to do the second option, is possible to do this? Using HttpClient class and GetMethod/PostMethod for the REST calls inside my Java Webscript may be the best option for Rest calls?. Or this could give me problems? Because I use a Rest call to my backed webscript that do another rest calls to another webscripts.
Thanks a lot!
I think it's bad practice to do it like this. In a lot of Alfresco versions the default services didn't change a bit. Even when they changed they still had deprecated methods.
The rest api changed as well. If you want to make an upgrade proof system I guess it's better to stick with the Webservices (which didn't change since version 2.x) or go with CMIS.
But then it doesn't make sense to have your code within Alfresco, so putting it within an interface is better.
I'd personally just stick with the JavaScript API which didn't change a lot. Yes more functions were enabled within, but the default actions to search & CRUD remained the same.
You could even to a duo: Have your Java Backendscript do whatever fancy stuff and send the result to je JavaScript controller and do the default stuff.
Executing HTTP calls against the process you are already in is a very very bad idea in general. It is slower, much more complex and error-prone, hogs more resources (two threads), and in your case, you will even lose transaction safety. Just imagine the last call fails for some reason. Besides you will most likely have to handle security context propagation yourself. Use the native public API and it will be easy, safe and stable.
I'm developing a system that integrates an existing Django application with a Magento store. I've managed, using this library, to create bundle-type products, along with attributes and categories as expected. The problem is that I can't find a way, using the SOAP API (either through the aforementioned library or calling the xmlrpc methods directly), to add products to a previously created bundle. Calling the catalog_product.info method doesn't return anything useful about the bundled objects.
Researching online, I've only found solutions that involve either:
PHP scripts that use the Magento code base
Straight-to-database insertion
Neither of these is currently an option for me right now, and I don't think being able to do this by using just the API (either REST or SOAP) isn't an irrealistic expectation to have.
You can export header information about a bundled product, so I assume you can import it back to Magento. However there does not appear to be a way to import component structure of a bundle. This would be a very complicated interface,
I am currently working on a REST service. This service has an entity which has different versions, similar to Wikipedia articles.
Now I'm wondering what I should return if for
GET /article/4711
Should I use a (temporary) redirect to the current version, e.g.
GET /article/4711/version/7
Or should I return the current version directly? Using redirects would considerably simplify HTTP caching (using Last-Modified) but has the disadvantages a redirect has (extra request, 'harder' to implement). Therefore I'm not sure whether this is good practice though.
Any suggestions, advise, or experiences to share?
(btw: ever tried search for "REST Version"? Everything you get is about the version of the API rather than entities. So please bear with me if this is a duplicate.)
If you treat versions as entities (which by the looks of it you do) this is what I'd suggest:
GET /article/4711
returns a list of all versions (and links to them). Which makes /article/4711 a container entity.
GET /article/4711/latest
returns contents of the latest version. You might want to consider /version/latest to get in-line with the below.
GET /article/4711/version/7
returns the specific version of the article.
Depends on your intended behavior for GET /article/4711. If it is intended to always point to the latest version, then it should return the latest version directly. Redirecting to a particular version seems problematic as you are relying on the user/client library to not visit that particular URL in the future. To translate into HTML terms, a user might bookmark the version/7 URL and be surprised that they are now accessing an older version instead of the up to date version they originally typed into the address bar.
You might want to look at https://datatracker.ietf.org/doc/html/draft-brown-versioning-link-relations .
Using the CMIS link relations and the HTTP Link header you can make /article/4711 the latest and provide a link to the versions, e.g. Link: </article/4711/versions>;rel=version-history
Article versions and hypertext
If you're really concerned about making the interface RESTful then you should consider how to do this in a HATEOS style.
In my opinion that would mean returning enough information that the user is able to navigate through the list of revisions of your entity. If you read this from Roy ...
"The interface doesn’t need to be discovered. It is defined right there in the hypertext. The representation tells the client how to compose all transitions to the next application state"
... you'll get a feel for how your GET /article/4711 should return enough information to
Get the latest version of the article
Get the next/previous versions
You'll know what works best for your model but as a pointer you could consider using tags
<link rel="older"
type="text/html"
href="http://www.yourdomain.com/article/4711?version=6"/>
...
I think it would be more restful to return a list of the revisions for:
GET /article/4711
You could also have:
GET /article/4711/current
Which returns the current version directly.