Jesper Joergensen
Jesper Joergensen
Yeah. At first glance that should be straightforward and fits well with the architecture where ResourceRepresentation delays deserialization On Mon, Jun 19, 2017 at 5:34 PM Mark Holton wrote: >...
Haven't had a chance to look at this in a while. Pull requests are much welcome! :-)
Which API version are you using? I am getting similar (but not necessarily same) errors when running tests with API version 40.
I am sorry but I can you clarify your question on DTO objects?
I see. No. It is explicitly not in scope for this project to maintain class representations of those objects. My hope is to make force-rest-api interoperate seamlessly with other projects...
Thanks! I will take a look when I find some time. On Mon, May 17, 2021 at 8:35 PM Baikang ***@***.***> wrote: > @ubinexy I add some test code on...
I am getting errors when running the tests: ``` [main] INFO com.force.api.http.Http - Bad response code: 400 on request: GET https://na111.salesforce.com/services/data/v51.0/search/?q=FIND+%7Bname%7D+IN+ALL+TYPE+RETURNING+Account%28name%29 [main] INFO com.force.api.http.Http - Bad response code: 400 on...
`instance_url` is available in `ApiSession.getApiEndpoint()`. `id` is not currently available but I believe it's just a pointer to the same resource as what you get with `ForceApi.getIdentity()`. Can you confirm?
Which method in ForceApi are you using? getSObject or get()? It would be great if you can send a pull request with a proposed fix that includes a test.
Sorry, I haven't touched this code in many many years and I don't remember the difference between 1.0 and 1.0a