I'm writing a middleware solution which should be able to take products from a specific source and add/update these to/in Magento.
Since there are products with different sizes/colors/etc I'll need to make use of Magento's configurable and simple products.
Adding the products does not expose a problem, linking a simple product to a configurable one however does.
Does anyone know how to accomplish this using the API?
I'm using C# and the v2 SOAP Magento API.
Using custom PHP code or CSV imports is not a possibility.
Thanks in advance!
This is not achivable via Standart API.
You should write your own.
We had project where we wrote Configurable API and other Company Java warehouse connector.
So you can try to directly access DB. Or try to find some module.
In Magento you can extend their API, either directly in the php code, or via a magento extension(preferred approach, as it allows you to upgrade magento). Neither of these approaches requires hitting the database directly. Rather you are using the serverside php api (lots of examples on the magento site) and using the php object/entity model and methods to do that.
Specifically the call that you're looking for in the product API is called getAssociatedProducts() This call is NOT availble in the webservices API, but you can call it via an extension that you write and make it available in the through the webservice API that way.
Alternatively you can get ALL of the products with attributes and try to link the association between configurables/simples that way, but that approach will obviously be much slower than the extension route.
Related
I want to develop a basic C# application that makes use of Microsoft Graph API to retrieve all user emails and contacts.
How would I approach this to implement it from scratch on Visual Studio?
I tried to add a method to do so in the provided sample, without success.
You can start with some of the QuickStarts
https://developer.microsoft.com/en-us/graph/quick-start
For example, you start with ASP.NET MVC quickstart and then expand it with additional controllers that would handle listing emails and contacts.
There is quite good SDK for .NET that you can use in your apps - it will make your development easier. The SDK enables you to write quite nice async calls instead of calling the API directly and composing your REST queries.
For example, to retrieve messages in user's mailbox you would make a call like
graphServiceClient.Me.Messages.Request().GetAsync();
It might be helpful to take some ideas from my demo app that I use for conferences - it is based on some Graph Labs
https://github.com/panjkov/Office365PlannerTask
Take a look at Groups and Tasks controllers, as well as corresponding data repository classes - there are methods to retrieve particular collections, as well to retrieve specific items.
I've got the task to connect a platform based on .net via a plugin to Typo3. I'm not very familiar with Typo3, but with the .net stack (actually using C#).
The requirements include writing data to Typo3 and retrieving data from Typo3.
Looking at the Typo3 API documentation (http://api.typo3.org/), I don't find any information on the interfaces I could use, or even how to stuff data into the system. I used all my favorite search engines, but ended up here. (Or I just searched for the wrong terms?!)
Following requirements have been provided additionally:
No writing/reading to/from the database (we don't get access to it for multiple reasons)
Use of a general solution (which could be re-used for different entities)
Synchronous process (so we get an error when inserting data has failed, etc.)
No batch import/export solution
Authentication must be used
What I search for is a simple interface which I can consume from my plugin. Something like SOAP, REST or any variant which I can call via http/https - including authentication.
Do you have an idea?
There is no external API built in TYPO3 out of the box.
Quick search for REST or SOAP based extensions (http://typo3.org/extensions/repository/) to provide e.g. page structure and contents from TYPO3 doesn't provide any results either.
The only solution is to write an own extension providing a SOAP or REST API to access TYPO3 data.
I have a Web API project (4.5) that has all the DTO objects stored in a separate project for simplicity. I was wondering if there is anyway to link from the Web API help page to these class libraries so that my end users can not only see what they need to send but so that they can see the XML comments on those objects specifying what each property of the object does/means.
I suppose you are talking on "WCF Web API Test Client",
AFAIK it uses Microsoft.AspNet.WebApi.WebHost.dll provided by Microsoft. The sources are not available but if it is not obfuscated you can change it after ILSPY.
Beside this you can't decorate it, normally you just redirect the page from global.asax.
Another option : Maybe you should write your own. But you will have much work with attribute reading and reflection :) Maybe you should start a project in CodePlex & git.
I am looking to get into doing some iOS development for a nice addition to a project i am running.
The main project is currently written in C# and is mainly asp.net with a few windows services.
I would like to incorporate this to be able to develop a basic iPhone app as a proof of concept.
From what i have read and understand, its generally best practice to use JSON as a communication medium for iOS.
I am thinking about using WCF to create the API methods so the iOS app can connect to these services to get the data.
Are there any nice tutorials to do this?
Take a look at:
Developing RESTful iOS Apps with RestKit
I do this all the time. WCF Data Services (OData) are the way to go. With OData services, you can specify that you want JSON response by passing (Accept - Application/JSON) in the HTTP Header and OData will return JSON to you.
I have used several libraries for getting OData (which are REST services) from iOS. Microsoft's iOS OData implementation is pretty lame. RESTKit does a really good job for what it handles, but is really painful if you have to do something that it doesn't. I have also used ASI - it is much more flexible than RESTKit, but is not without problems. I ended up writing my own and it suits me just fine.
For a beginner, I would recommend using ASI over RESTKit. RESTKit, while doing a lot of the heavy lifting for you, takes a bit to get working right.
There are two things that are not standard when receiving JSON responses from OData.
1. All responses are captured in a JSONDictionary with the key of "D".
2. Dates are serialized to the JSON standard (number of seconds since 1970), but they are placed in a string like so: /Date(1212353), so you will have to parse out the Date() part of the string before you can use it.
RESTKit doesn't handle either one of these issues natively, so you will have to deal with them if you choose that route. Personally, I would go the ASI route until you learn enough to write your own.
I am considering open sourcing my solution - if I do, I will update this response with the link to it.
---UPDATE----
Just to be clear - if your server side system uses WCF Data Services, otherwise known as OData, then with minor tweaking, RESTKit plays nice with it. If your services are traditional WCF Services (i.e. SOAP Binding), then you will not be able to get JSON out of them because they are bound to the SOAP protocol (Unless you create a custom Behavior to translate it - which I wouldn't do). It all depends on what your services do in essence. If your services are typically data exposure/manipulation (i.e. addCustomer), then you should expose them as OData. If they are truly operations, then you should maybe consider exposing them as actions from a MVC site. Either of them can get you REST services using your existing infrastructure and platform.
If you're using Objective-C to develop the iPhone app, I'm not sure WCF is the best web service technology to use on the server. Check out ServiceStack to create a RESTful service.
Refer following link:
http://www.kotancode.com/2011/04/26/backing-your-ios-app-with-wcf-json-web-services/
It has included comprehensive code samples as well.
Recently, I've been very interested in APIs, specifically in how to create them. For the purpose of this question, let's say that I have created an ASP.NET MVC site that has some data on it; I want to create an API for this site.
I have multiple questions about this:
What type of API should I create? I know that REST and oData APIs are very popular. What are the pros and cons of each, and how do I implement them? From what I understand so far, REST APIs with ASP.NET MVC would just be actions that return JSON instead of Views, and oData APIs are documented here.
How do I handle writing? Reading from both API types is quite simple. However, writing is more complex. With the REST approach, I understand that I can use HTTP POST, but how do I implement authentication? Also, with oData, how does writing work in the first place?
How do I implement basic rate-limiting and caching? From my past experience with APIs, these are very important things, so that the API server isn't overloaded. What's the best way to set these two things up?
Can I get some sample code? Any code that relates to C# and ASP.NET MVC would be appreciated.
Thanks in advance!
While this is a broad question, I think it's not too broad... :)
There are some similar questions to this one that are about APIs, but I haven't found any that directly address the questions I outlined here.
A REST service can return any media-type. It could be a standardized one listed at IANA, or it could be a custom one created by you.
OData is a protocol built on to of AtomPub. AtomPub itself is RESTful, however, OData currently breaks a few of the REST constraints.
Authentication of a RESTful service is best done using the HTTP Authorization header.
You write to an OData service the same way you do with an AtomPub service. Read the spec.
Personally, I would worry about writing a valuable service that delivers content efficiently before worrying about rate limiting. You can be happy when you finally run into that problem.
For more information on caching, read this.