Extra metadata unavailable in libspotify (ISRC, UPC) - metadata

The libspotify documentation for the Track subsystem makes no mention of metadata. You can see that extra metadata (such as ISRC) is present by using the XML Metadata API:
http://ws.spotify.com/lookup/1/?uri=spotify:album:6G9fHYDCoyEErUkHrFYfs4&extras=trackdetail
<album><name>Remedy</name><artist href="spotify:artist:4YrKBkKSVeqDamzBPWVnSJ"><name>Basement Jaxx</name></artist><released>1999</released><id type="upc">634904012922</id><tracks><track href="spotify:track:3zBhJBEbDD4a4SO1EaEiBP"><name>Rendez-vu</name><artist href="spotify:artist:4YrKBkKSVeqDamzBPWVnSJ"><name>Basement Jaxx</name></artist><available>true</available><id type="isrc">GBBKS9900090</id><disc-number>1</disc-number><track-number>1</track-number><length>346.158000</length><popularity>0.37000</popularity></track>[...etc...]
Here the album has a UPC code and each track has ISRC. Will this ever be available through libspotify or does it need a second query using the XML Metadata API once I've got album/track links from the API?

Related

NetSuite and SuiteTalk list all of a type (paged or not)

I am currently trying to work with the SuiteTalk 2017_2_0 API for a new integration with NetSuite. I have all the basics rolling of single record retrieval, etc.; however, I am having a problem trying to figure out how to list all of a given object/type in the system.
Example: I want to list ALL InventoryItem data.
Not sure what I am missing. Does anyone have a sample SOAP doc?
What I did so far
I have been working primarily with types: Sales Order, Customer and Inventory Item.
Tried using the getAll call defined in the WSDL - only supports limited fields:
budgetCategory
campaign*
currency
etc.
Tried using getList but a set of internal IDs are required in the baseRef/RecordRef (INVALID_KEY_OR_REF - The specified key is invalid.)
Fails:
<urn:getList>
<urn1:baseRef xsi:type="core:RecordRef" type="salesOrder" />
</urn:getList>
Succeeds:
<urn:getList>
<urn1:baseRef xsi:type="core:RecordRef" type="salesOrder" internalId="1" />
<urn1:baseRef xsi:type="core:RecordRef" type="salesOrder" internalId="2" />
</urn:getList>
Tried formulating a search that would return all the data but the types I need are unavailable (or I haven't been able to figure it out)
Define a saved search that pulls the appropriate data, then call the saved search.

How to provide translations for field names with Symfony2/Doctrine2 via REST?

We have a backend built on FOSRestBundle (JMSSerializer) based on Symfony2/Doctrine2.
Our API e.g. delivers for some entity something like: 'valid_from': '2015-12-31' in a REST/JSON response.
Our AngularJS frontend consumes this REST API and e.g. presents some form to the user:
Valid from: 31.12.2015
Now I am wondering what's the best way to have a central/or maintainable place for a mapping like:
an English label for field key 'valid_from' is 'Valid from'
To my understanding all Translatable extensions for Doctrine (like Gedmo Kpn etc.) are to translate content (e.g. 'category' = 'Product' in English and = 'Produkt' in German) but not schema.
And of course I cannot change/adapt the field key to the language because it's the identifier for the frontend.
What I thought so far:
Use some mapping file between field_key, language_key and
translation on frontend.
Issue here is that the frontend needs to know a lot and ideally any change in the API can be done thoroughly by the backend developers.
Use some mapping file between field_key, language_key and
translation on frontend.
As we use annotations for our Entity model and JSMSerializer I'd need to open a totally new space for just translation information. Doesn't sound too convincing.
Create custom annotation with properties
Current idea is to use custom annotation (which would be cacheable and could be gathered and provided as one JSON e.g. to the frontend) with my entity properties.
That means any backend developer could immediately check for translation keys at least as soon as the API changes.
Something like:
#ORM\Column(name='product', type='string')
#FieldNameTranslation([
['lng'=> 'de-DE'],['text']=>'Product'],
['lng'=> 'en-En'],['text']=>'Produkt'])
A further idea could be just to provide some translation key like:
#FieldNameTranslation(key='FIELD_PRODUCT')
and use Symfony's translation component and have the content in translation yml files.
What is your opinion? Is there any 'best in class' approach for this?

How to design complex update actions in REST API

I'm currently working on a REST API, trying to design it with most best practices as possible.
I work with Symfony2 PHP framework but some of my questions are valid for any REST API i guess.
Starting from the base design for a particular resource :
GET /resource - Get all resources
POST /resource - Create resource
GET /resource/{id} - Get resource with id={id}
PUT|PATCH /resource/{id} - Edit the resource with id={id}
DELETE /resource/{id} - Delete the resource with id={id}
Supposing my resource has complex rules while updating.
It has a "status" field, (a float for example), that can be updated only by following a particular scheme
It has a "schedule" field (a datetime), with different choices available that are not always the same
How am I supposed to expose those rules to the API consumer ? For the schedule field, how am I supposed to provide the different choices available at the current time ?
About the Symfony server-side part, I followed most of the recommandations of this walkthrough : http://williamdurand.fr/2012/08/02/rest-apis-with-symfony2-the-right-way/
My POST, PUT & PATCH actions are handled with Symfony Forms, so most of the rules are processed by Symfony constraints/validations features.
But form binding is quite limited, let's supposed I want to trigger a particular event if the user change the status field from 2 to 3? What is the best way to do that ?
Thanks in advance.
HTTP has another verb you aren't using: OPTIONS. You can use this to list the schedule options.
Here's a blog article about it: http://zacstewart.com/2012/04/14/http-options-method.html
As for updating the status, I would reuse POST and include an action in the field. Example:
POST
{
"type": "update",
"status": 3
}
Modified REST:
GET /resource - Get all resources
POST /resource - Create resource
GET /resource/{id} - Get resource with id={id}
PUT|PATCH /resource/{id} - Edit the resource with id={id}
DELETE /resource/{id} - Delete the resource with id={id}
OPTIONS /resource/{id} - Retrieve options of resource with id={id}
Keep in mind that you can pass params along in the body for everything but GET and you can pass any params in the URL for GET.
I have zero knowledge on Symfony2, so I'll just concentrate on your more generic REST how-to qustion about exposing rules.
Give the consumers of your REST API a documentation. It's the first thing they will hit before actually playing with your API. Use tools for that, from auto-generated help pages to 3'rd party providers like Apiary.io or alike.
Create meaningful responses when consumers send "wrong" requests: use correct http response status codes (Bad request, Conflict, etc.) when request parameters are missing or invalid.
If your REST api is relaxed, it can also include information about what went wrong and how to resolve the problem in the response body.
What worked well for me in the past was to have a generic ErrorMessage entity that was returned upon each non-successful request, containing a title, an error description, and a dedicated more technical "dev-description" which can be enabled/disabled for test/production on the server side.
In my case, my consumers all know that they can get either the expected response entity in case of success, or that generic ErrorMessage entity in the response in case of failure.
If you can desribe your rules, why not provide those as meta information for your service? Eg. in my case I know I have a set of parameters, each having a set of available options. Think of the parameters as the key in a query string, and the options as the values for that key. In a complex world, parameter options depend on other parameter options, eg. in my case the available options for parameter B are dependent of what option(s) are "selected" for parameter A. I can expose those dependencies by providing a "metadata" resource in my REST api, eg. a JSON stucture listing all parameters and all options for those parameters, and for each option adding a "requires" section desribing that that option is only "available" if parameter xy has selected option p and q.
This allows my consumers to - with a single request to that meta data resource - create a "state-machine" on the client side. I hope you get the picture.
Here is my understanding of REST-full way to handle updates and advertise update operations to API client.
This is based on this wonderful book and Fowler's article about REST with some additions of File Levels of Media Type and article about Restfull CQRS. Basically you use PUT for update and pass the operation via content type and advertise content type via mediaType in hypermedia controls.
All operations which are available for current state of your resource are listed among hypermedia controls which are passed with representation of resource like this:
<myresource>
<status>ACTIVE</status>
<some-field with-attribute="value"/>
<some-other-field/>
<!-- other fields representing state of resource -->
<link rel = "self"
uri = "/resource/1234"/>
<link rel = "/linkrels/resource/changeStatus"
uri = "/resource/1234"
mediaType = "application/vnd.myapp+xml;domain-model=ChangeStatusCommand"/>
<link rel = "/linkrels/resource/changeSchedule"
uri = "/resource/1234"
mediaType = "application/vnd.myapp+xml;domain-model=ChangeScheduleCommand"/>
<link rel = "/linkrels/help"
uri = "/help/resource"/>
</myresource>
Links together with mediaType gives enough information what command is allowed. In many cases this should be something very specific to current state of resource. For example if you can move it from status ACTIVE to TRASHED than command should be named not StatusChange but TrashCommand and so on.

WCS7 best practice to receive certain catalog entry information?

[WCS 7, FixPack 7, Feature Pack 6]
I need to generate a feed with certain catalog entry (product) information such as name, image(s), category, price, seo-url, descriptive attributes and so on.
To generate this feed i will use the scheduler framework and created a controller command which will be invoked after a certain time has passed.
Now i need to receive the catalog entry data of each item in a specific store/catalog.
As far as i know there are several ways to achieve this:
Access Beans
SOA (new Access Profile with specific SQL)
I tried to use Access Beans to get all necessary information but I got stuck with seo-url, price etc.
Are there more ways and what is the best practice to get a specific set of catalog entry attributes?
I suggest you study/investigate in your WCS Development environment how site map generation schedule command is implemented (SitemapGenerateCmd) and how it is calling the JSP template file (sitemap.jsp)
you need to modify a bit in your command to create a jsp template for your feed and call that template from your scheduler command you've created .
calling template command for messaging system, make sure to use following properties in ActionForward tag to register the JSP for messaging from back-end:
example:
<forward className="com.ibm.commerce.struts.ECActionForward"
name="SitemapIndexView" path="/SitemapIndex.jsp">
<set-property property="direct" value="true"/>
<set-property property="resourceClassName" value="com.ibm.commerce.messaging.viewcommands.MessagingViewCommandImpl"/>
<set-property property="interfaceName" value="com.ibm.commerce.messaging.viewcommands.MessagingViewCommand"/>
<set-property property="properties" value="storeDir=no"/>
<set-property property="implClassName" value="com.ibm.commerce.messaging.viewcommands.MessagingViewCommandImpl"/>
</forward>
then the logic for extracting data from your product/catalog beans will be handled inside the JSP and you can easily form the output data as you want (XML, CSV, JSON .. etc)
the advantages and benefits of using this way are you can leverage Commerce Server OOTB JSTL tags , WCF tags for retrieving all information and using wcf:url for SEO URLS OOTB even you can call BOD/SOA commands using <wcf:getData tag and finally your will get more structured design that can easily maintain and reuse in future .
sitemap.jsp is a good resource for you how to iterate through catalog and sub-catalog to extract product info.
hope that those help you find your solution. need some search and understanding of existing sitemap generation utility .
Thanks.
Abed

Facebook batch operations custom object

I am trying to make some batch operations for custom objects that I have created oat Open graph API. I have seen tons of examples for feeds or images, but I still do not know if Facebook supports batch operations for custom objects. For example, I'd like to know if a batch operation for the following objects would work:
batch=[
{:method=>"post", :relative_url=>"/me/tfgtopquiz:win", "profile"=>"users/1/victories"}
{:method=>"post", :relative_url=>"/me/tfgtopquiz:guessed", "triviaquestion"=>"questions/1"} ]
Notice that I have custom types (triviaquestion). It seems that if I pass it as a parameter facebook ignores it, and I would need this information. After the request, I get this error message:
"The action you're trying to publish is invalid because it does not specify any reference objects. At least one of the following properties must be specified: triviaquestion."
I really tried to define the type "triviaquestion", but it looks like Facebook ignored it iside batch JSON.
Any thoughts?
Thanks!
After some time I realized that I should send the JSON in other format:
{:access_token=>"MY_ACCESS_TOKEN",
:requests=>
[{:action=>"guessed", :object_type=>"triviaquestion", :object_url=>"URL"},
{:action=>"guessed", :object_type=>"triviaquestion", :object_url=>"URL"},
{:action=>"guessed", :object_type=>"triviaquestion", :object_url=>"URL"},
{:action=>"play", :object_type=>"correct_answer", :object_url=>"URL"}]}
Thanks!