Create Salesforce Case object with nested relationships using REST API - api

I am attempting to create a new Case object using the REST API but need to find out how to format the JSON body to pass in nested SObjects.
It's not apparent in the Docs, and I can't seem to find any examples. Anyone have any pointers or have done this before?
The SF web UI uses a text lookup field to set the (related) Contact and Account, and I need to figure out how to either bypass the need for a lookup or embed the SObjects of the related records in the JSON.
[{"message":"The value provided for foreign key reference Contact is not a nested SObject","errorCode":"INVALID_FIELD"}]

Figured it out by simply setting the AccountId and ContactId attributes on the new Case object.

I also haven't seen any documentation about this, but if you look at the object metadata returned by the REST API for any standard object, it seems that the suffix 'Id' is appended to any field of type "reference". For example, Case has OwnerId, LastModifiedById, CreatedById, etc. This suffix is not present in the field names displayed in the browser interface. The WSDL for the SOAP API includes both the ID as a simple element of type "ID", as well as a complex child element for nesting the actual record.

Related

How to get actual allowed values instead of reference to it with Attributes api in Rally

https://rally1.rallydev.com/slm/webservice/v2.0/typedefinition/<defect_id>/Attributes
After hitting the specified url we get the fields for the specified defect id but in order to fetch the allowed values for dropdown fields we have to hit another api.
Is there any other way through which we can get all the fields with the allowed values instead of the reference to the allowed values in a single api call?
Unfortunately with the introduction of WSAPI version 2.0, the ability to load sub collections of data within the initial request was removed. This was done in order to improve performance as it was previously possible to request too large a set of data and have a significant impact on the performance of the system.
So the only way to fetch the lists of allowed values for fields is to loop through the list of defect attributes, grab the necessary endpoint url from the _ref value and load it from there.
It could be worth saving the references to these attribute IDs as they shouldn't change as long as the fields aren't removed from the object model.

Identifier in DTO when POSTing in Web API?

I have a Web API and I am using DTOs to abstract the underlying data model from the client. I have [at the moment] one DTO per controller. This DTO in all cases contains the database id of the data being passed about. On a GET, PUT, DELETE this makes sense (although DELETE and GET just use the id and not the DTO on the request obviously), but on the POST it doesn't make sense as the new data being added has no id yet.
In other words I am asking the client to pass to the API a structure that includes an Id field but I will ignore the content of that Id field. Is this acceptable or should I create an UpdateDTO and a RetrieveDto?
Keep the data structure you have. Make the Id field optional. If the value of Id is set when a POST comes in, return an error.

Google Plus Activity list 'id' deprecated

I am trying to retrieve the list of activities for a given {user_id} using the following url end points
GET https://www.googleapis.com/plus/v1/people/106125369682295685477/activities/public?key={YOUR_API_KEY}
I am trying to look at the response and the documentation says that id field of an activity is deprecated.
Then how do we identify the uniqueness of a post from google plus if the id field is deprecated. Any help on this issue would be appreciated.
The idof an activity hasn't been deprecated and can still be use to uniquely identify a post. This id is also used as parameter in other methods like comments.list
What has been deprecated is the id of the activity list. Instead of this field the etag field of the activity list response can now be used to check whether it's a new list or a cached response without changes.

Include count of linked records in OData result

I've got a table "Events" with a linked table "Registrations", and I want to create an OData service that returns records from the Events table, plus the number of registrations for each event. The data will be consumed client-side in JavaScript, so I want to keep the size of the returned data down and not include all linked registration records completely.
For example:
ID Title Date Regs
1 Breakfast 01.01.01 12:00 4
2 Party 01.01.01 20:00 20
I'm building the service with ASP.NET MVC4. The tables are in an MSSQL database. I am really just getting started with OData and LINQ.
I tried using the WebAPI OData system first (using classes of EntitySetController) but was getting cryptic server errors as soon as I included the Registrations table in the entity set. ("The complex type 'Models.Registration' refers to the entity type 'Models.Event' through the property 'Event'.")
I had more success building a WCF OData system, and can request event information and information on related registrations.
However, I have no clue how to include the aggregate count information in the event result set. Do I need to create a custom entity set that will be the source for the OData service? I probably included too litte information here for finding a solution, but I don't really know where to look. Can somebody help me?
If you're willing to make an extra request per Event, you could query http://.../YourService.svc/Events(<key>)/Registrations/$count (or http://.../YourService.svc/Events(<key>)/$links/Registrations?$inlinecount=allpages if you're also using the links to the Registration entities).
Examples of both of these approaches on a public service:
http://services.odata.org/V3/OData/OData.svc/Suppliers(0)/Products/$count
http://services.odata.org/V3/OData/OData.svc/Suppliers(0)/$links/Products?$inlinecount=allpages&$format=json
I'm guessing that you'd prefer this information to come bundled together with the rest of the Events response though. It's not ideal, but you could issue a query along these lines:
http://services.odata.org/V3/OData/OData.svc/Suppliers?$format=json&$expand=Products&$select=Products/ID,*
I'm expanding Products (analogous to your Registrations) and selecting Products/ID in order to force the response to include an array that is the same size as the nested Products collection. I don't care about ID -- I just chose a piece of data that would be small. With this JSON response, your javascript client can get the length of the Products array and use that as the number of Products that are linked to the given Supplier.
(Note: to have your service support $select queries using WCF Data Services, you'll need to include this line when you initialize the service: config.DataServiceBehavior.AcceptProjectionRequests = true;)
Edit to add: The approach using $expand and $select won't be guaranteed to give you the correct count if your server does server-driving paging. In general, there isn't a simple single-response way to do what you're asking for in OData v3, but in OData v4, this will be possible with the new expand/select syntax.
i'm using oData v4 and i used this syntax :
var url = '.../odata/clients?$expand=Orders($count=true)';
// ...
a field called Orders#odata.count has been added to the response entity which contains the correct count.
and now to access the JSON property containing a dash you have to do it like this :
var ordersCount = response.value['Orders#odata.count'];
hope this helps.
Can you edit your Event model and add a RegistrationCount property? That'd be the simplest way I think
What I ended up doing was actually very simple; I created a View in SQL Server that returns the table including the registration counts. Never thought about using a view, since I've never used them before...
I used this to get the child count without returning the entities:
/Parents$expand=Children($count=true;$top=0)

How to design RESTful URL with many input parameters

I am working to create a Java based RESTful API that uses Spring MVC.
Now for some of the API endpoints-- multiple different parameters are required... I am not talking about a list of values-- more like parameter1, parameter2, parameter3, parameter4 and so on-- where all the 4 (or more) parameters are of different data types as well.
How do I design the API endpoint URL for the above scenario, eg for 4 separate input parameters? Is there any recommended way/best practice for doing this? Or do I simply concatenate the 4 values, with ach pair of values separated by a delimiter like "/"?
EDIT from user comment:
Example: I have to retrieve a custom object(a 'file') based on 4 input parameters--(Integer) userid, (Integer) fileid, (String) type, and (String) usertype. Should I simply create a REST Endpoint like "getfile/{userid}/{fileid}/{type}/{usertype}-- or is there a better (or recommended way) to construct such REST endpoints?
In REST start by thinking about the resource and coming up with immutable permalinks (doesn't change)to identify that resource.
So, in your example (in comment), you said you want to retrieve a file resource for a user and type (file type or user type?)
So, start with just enough information to identify the resource. If the id is unique, then this is enough to identify the resource regardless of the user who owns the file:
/files/{fileId}
That's also important as the url if a file could change owners - remember we want to identify the resource with just the components needed so it can be a permalink.
You could also list the files for a specific user:
/users/{userId}/files/
The response would contain a list of files and each of those items in the list would contain links to the files (/files/{fileId})
If for some reason the file id is not unique but is unique only in the context of a user (files don't change owners and id increments within a user - wierd) then you would need these components to identify the resource:
/users/{userId}/files/{fileId}
Also note the order based on the description. In that wierd case, we said the files are logically contained and IDed by the user and that's also the containment in the url structure.
Hope that helps.
A GET request to file/{usertype}/{user}/{type}/{fileid} sounds good