REST API - Initial Implementation

[maxrice]

This is the initial version of the REST API, #3175. It is still very experimental but ready for feedback and testing.

Authentication is handled two ways. First, if Force Checkout SSL is enabled, the API index declares support for SSL and API requests can be easily authenticated by passing the consumer key and secret key as HTTP Basic Auth username/password.

If SSL is not available, API requests must be signed according to the OAuth 1.0a spec, implemented as "one-legged" OAuth. This means that every request is signed and authenticated instead of the consumer receiving a token for future use. While it's somewhat of a pain to implement, it's the only way to ensure requests are secure when using plain HTTP.

To test/review, pull this branch and comment out or remove this filter so you don't have to authenticate. All endpoints are at http://example.com/wc-api/v1/. I'll update this list of endpoints as implementations are finished.

Index
GET /

Orders
GET /orders
GET /orders/count
GET /orders/<id>
GET /orders/<id>/notes

Coupons
GET /coupons
GET /coupons/count
GET /coupons/<id>
GET /coupons/code/<code>

Customers
GET /customers
GET /customers/count
GET /customers/<id>
GET /customers/<id>/orders

Products
GET /products
GET /products/count
GET /products/<id>
GET /products/<id>/reviews

Reports
GET /reports
GET /reports/sales

Open Questions

• What is the proper permission check for count methods? e.g. GET /orders/count

Closed questions

• This uses some code from the WP API project, mainly the WP-JSON-Server class. It makes routing and other response-related stuff outrageously easy. My only issue is that it couples a JSON response type very tightly to the routing, which makes it impossible for us to support XML-based responses.
  *I think the routing handling could be refactored into a base class, and two sub-classes created, one to handle JSON and the other to handle XML. This would also make it easier to make the entire class more WooCommerce-specific, which prevents any unexpected conflicts if a user is running the WP-API as a plugin on their server, or if it's merged into WP core.
• How should order/coupon/product/customer meta be implemented?I like the idea of a meta attribute for each of the response objects that can be enabled with something like ?include_meta=true or similar in the request. will be implemented as resource-specific product_meta attributes. Clients will indicate they want meta returned in response by including meta=true in filter parameter.
• Should get_json_url() and json_url() be prefixed? yes and refactored to return canonical WC-API URL.
• Global functions to create orders/products would be very helpful in reducing code duplication. Order/Product clones of woocommerce_create_new_customer would be perfect creating orders and products via the API will be pushed to WC 2.2
• /orders returns orders with any status by default, should default be processing/completed instead? orders will include any status by default
• should totals be cast to string so they're string quoted in json response? totals will be cast as string
• When requesting a variation ID, should the response include only the variation product? or should it include the variable parent product, and the requested variation listed as the only variation? variations will return the same set of data as a regular product, with the parent variable product data included as a top-level attribute.
• Should the /coupons endpoint have a custom parameter for getting coupons by coupon code? The q parameter searches both code/description already a new endpoint will be added
• API keys are currently 1 per user (and API requests run under the WP permissions of that user), should we support multiple keys per user? API keys will be serialized into a single user meta entry to support multiple keys
• should API secret keys be hashed prior to storage? This would prevent accessing the plaintext key again after it's displayed + stored secret keys cannot be hashed because we need them in plaintext to calculate the OAuth signature for plain HTTP requests
• We need to require WP 3.7 in order to allow date filtering, any obvious problems with this? It degrades gracefully for pre-3.7 versions WC 2.1 will bump the minimum WP version required to 3.7
• Since the v1 API won't support creating products or orders, should the DELETE method be removed for those endpoints as well? DELETE endpoints will be removed and added along with PUT/POST in 2.2
• Should responses be consistent with use of a blank string or null for non-values? currently it's a mix null will be used for values that aren't set
• Should we rename legacy wc-api endpoint to wc-ipn to prevent confusion with REST API? not in 2.1, maybe 2.2

Todos

General

• Refactor WP_JSON_Server to WC-specific API server to handle JSON and XML, completed in SHA: maxrice@ed6de29
• Add store-specific information to API index, like currency, base location, etc, completed in SHA: maxrice@ed6de29
• Permission checks for reading/editing/deleting (via resource-specifc helper methods with current_user_can checks)
• Date standardization for requests/responses (completed in SHA: maxrice@87ff36d)
• filter_response_fields() method should support specifying sub-fields, e.g. billing_address.country (completed in SHA: maxrice@3130369)
• Refactor ID checks into base class method (completed in SHA: a13a95e)
• Refactor resource method names to snake_case (completed in SHA: a13a95e)
• Improve Navigational/Total count response headers (completed in SHA: maxrice@490dc75)
• Scope filter params like q, limit, offset and date filters behind brackets, like GET /orders?filter[q]=search (completed in SHA: a13a95e)
• Allow clients to specify the requests should include meta by adding to the filter parameter, like GET /orders?filter[meta]=true (completed in SHA: maxrice@48e8363)

Products

• Implement GET method (completed in SHA: maxrice@674ea42)

Customers

• Support created_at_min/created_at_max with pre_user_query filterusing this (completed in SHA: maxrice@1f5db98)
• Implement pagination (completed in SHA: maxrice@490dc75)
• DRY valid user checking code (completed in SHA: maxrice@a13a95e)

Coupons

• Implement GET /coupons/code/foo endpoint (started in SHA: maxrice@a13a95e, completed in SHA: maxrice@5ab8e08)

Reports

• Implement GET for Sales Report method (completed in SHA: maxrice@c1854b2)

Authentication

• Implement API-key based read/write permissions (completed in SHA: maxrice@ef22f03)

Settings

• Hook up settings to authentication class (completed in SHA: maxrice@61fb0f7)
• Implement key management (completed in SHA: maxrice@f542ce8)

TBD (in order of importance)

1. Implement API request logging - probably a new tab in Reports see Add request logging to REST API #4159
2. Orders - Implement PUT method, particularly for updating status of an order see Add PUT/POST/DELETE methods to Orders API endpoint #4160
3. Customers - Implement POST and PUT methods see Add PUT/POST/DELETE methods to Customers API endpoint #4162
4. Coupons - Implement POST and PUT methods see Add PUT/POST/DELETE methods to Coupons API endpoint #4163
5. Implement XML parsing/generation see Add XML output for REST API #4165
6. Products - Maybe implement PUT method see Add PUT/POST/DELETE methods to Products API endpoint #4164
7. Allow un-authenticated access to GET /products - this needs to be very carefully tested to make sure we don't accidentally expose sensitive information. We might even consider an entirely new endpoint so it can be sandboxed. see Allow unauthenticated access to Products API endpoint #4166
8. Consider allowing multiple API keys per user, probably don't need to bother since it's easy enough just to create a new WP user and assign keys that way. should wait on user feedback before implementing this

Documentation

• In-progress at http://docs.woothemes.com/document/woocommerce-rest-api/

[rmccue]

Sorry, I owed you an email about this earlier! I won't have time to look at this until next Wednesday at the earliest, but quick comments:

My only issue is that it couples a JSON response type very tightly to the routing, which makes it impossible for us to support XML-based responses.

You should be able to subclass and override this fairly easily, although come to think of it, some JSON stuff is mixed in with the rest, so that should be separated in WP-API.

Authentication is handled two ways.

We also need to handle this in WP-API, so anything here will help us out too. You should be able to implement OAuth completely via a custom authentication handler rather than in the server itself too (although I've haven't checked how you've done this).

How should order/coupon/product/customer meta be implemented? I like the idea of a meta attribute for each of the response objects that can be enabled with something like ?include_meta=true or similar in the request.

The idea with WP-API is that WC-specific data could either be added to the top-level (if it's at /products/:id or similar) or self-contained in a woocommerce attribute (for normal /posts/:id).

Using meta here is a Bad Idea(tm), since WP-API uses meta everywhere for things relating to the response itself. product_meta would be a better idea. Take a look also at how WP-API uses contexts for deciding the data to output.

Should get_json_url() and json_url()

Those should definitely be WC-prefixed unless you wholesale bundle WP-API (which is probably a Good Idea). If it makes it easier, we might be able to factor some of the classes out into separate repos. Also happy to look at refactoring code if it makes it easier for you to use now, but I don't want to move around too much just for the plugin-stage of WP-API, since we're aiming for core integration in 3.9.

Permission checks for reading/editing/deleting (via generic getResource() call with current_user_can checks)

I'd mix the current_user_can checks in with the actual data gathering, as it makes it much clearer as to what you're actually checking, and the context.

Refactor method names to snake_case if refactoring routing class

If those are in WP-API, patches would be welcome there. :)

Add Navigational/Total count response headers

If you've got a query, there's a helper method for that. If not, I'd base it off that method.

should totals be cast to string so they're string quoted in json response?

I'd go with yes. Storing/transmitting prices as floating point numbers is a Bad Idea.

When requesting a variation ID, should the response include only the variation product? or should it include the variable parent product, and the requested variation listed as the only variation?

I'd return the variation product, with the parent embedded (ala post parents).

Should the /coupons endpoint have a custom parameter for getting coupons by coupon code? The q parameter searches both code/description already

/coupons/:code might be appropriate here.

---

I'll take a more indepth look next week. :)

It makes routing and other response-related stuff outrageously easy.

[rmccue]

Oh also:

This would also make it easier to make the entire class more WooCommerce-specific, which prevents any unexpected conflicts if a user is running the WP-API as a plugin on their server, or if it's merged into WP core.

I'd really encourage waiting. If you can't wait until core integration, I'd at least wait until we hit 1.0, as I'm planning to begin ensuring compatibility from that point onwards. In that case, you can bundle the class and conditionally load it if you can't find it in core.

[coenjacobs]

Real awesome work so far, @maxrice! I'll get to this in more detail later today. Just a couple quick answers on the most critical parts of this discussion, so this can continue.

@maxrice

@coenjacobs - any ideas on where the documentation for this should live? I'd like to start adding to it now.

Fine to add it to the documentation site for now. Think that's a good habitat for it. :)

@rmccue

I'd really encourage waiting. If you can't wait until core integration, I'd at least wait until we hit 1.0, as I'm planning to begin ensuring compatibility from that point onwards. In that case, you can bundle the class and conditionally load it if you can't find it in core.

I can understand what you are saying, but at the same time we really want this API in v2.1 of WooCommerce. Having full forward compatibility for when the API hits WordPress core is obviously a very nice to have, but since this is not going to happen for WordPress 3.8 (correct me if I'm wrong) that's going to take a bit too long. I think it should be pretty well possible to keep it compatible on the end users side completely, while we change the underlying structure some more as soon as the API plugin matures? Until that is stable enough, or possibly going into core, I say we rely on our own code base only and not check for the API being present yet.

@maxrice We can continue this way, if it's up to me. We can use the API plugins code already, but lets not add any checks for that plugin (or the API in core) being active for now, so this will continue to work no matter what.

I really want this to integrate nicely with the API plugin as soon as it hits WordPress core, but we need to go forward as well and we've postponed the API for too long already. Plus, I think it's a nice way to test the actual code already and contribute back to the API plugin. :) Makes sense? I hope so, but just let me know if not.

[rmccue]

I can understand what you are saying, but at the same time we really want this API in v2.1 of WooCommerce. Having full forward compatibility for when the API hits WordPress core is obviously a very nice to have, but since this is not going to happen for WordPress 3.8 (correct me if I'm wrong) that's going to take a bit too long.

Yep, that's correct. The (unofficial) plan is to hit 1.0 on the plugin and freeze the internals at that point so that things like this can go ahead and be 100% compatible with whatever ends up in core.

I think it should be pretty well possible to keep it compatible on the end users side completely, while we change the underlying structure some more as soon as the API plugin matures? Until that is stable enough, or possibly going into core, I say we rely on our own code base only and not check for the API being present yet.

From 1.0 onwards, only the higher layers (posts/etc) should change, so it should be possible to rely on the API not changing majorly from then onwards. I have a few things that I'd like to get handled before then, but not that much. (And I'm yet to raise these with the team, but I plan to as soon as I'm back up to full capacity.)

Don't get me wrong, I want a WC API yesterday, but making sure it's forwards compatible is nice. :)

[coenjacobs]

I've discussed the forward compatibility today with @maxrice and we've agreed on the following: We're continuing the development of the REST API as we're doing now, where we're basing it on the WP-API project, but are not using that directly. This way we can help contributing to the original project as our project matures as well, while we don't have to wait for 1.0 of the WP-API before we can do anything. Time is really becoming our biggest issue with version 2.1 and we feel there is a good way around potential issues.

As soon as WP-API hits WordPress core, we are going to introduce the v2 of our API, this time completely based on the core implementation of the API. We'll bump the minimum required version of WordPress for the version of WooCommerce implementing the core API, while v1 of our API is going to stay in that WooCommerce release. That way we make the use of the new API opt in and we can make sure that nothing breaks. We can then deprecate v1 of our API quickly after that and make sure v2 is doing it the right way.

Yes, this might lead to some extra work now, but we think it's worth it to have an API sooner than WP-API is going in WordPress core, with all the goodies we've got coming up that are now waiting on the API. :)

@maxrice

How should order/coupon/product/customer meta be implemented? I like the idea of a meta attribute for each of the response objects that can be enabled with something like ?include_meta=true or similar in the request.

I agree with @rmccue here, using meta is bound to get conflicts (if not with core, it will be with some other plugin):

Using meta here is a Bad Idea(tm), since WP-API uses meta everywhere for things relating to the response itself. product_meta would be a better idea. Take a look also at how WP-API uses contexts for deciding the data to output.

Maybe this is far fetched, but what about having separate calls for the meta values, or is that really overthinking it now? If we're going with product_meta, we'll have to look into a small naming convention so we can do the same for orders, customers etc.

Should get_json_url() and json_url()

Yes, but please give these a wc_ prefix as @rmccue said for now, so we're not running into any conflicts.

WP 3.7 is required for date filtering, anyone have issues with this?

Not for me, but I'd like @mikejolley to confirm that we can bump the required version for WooCommerce 2.1 to WordPress 3.7. I'm not seeing any issues with it, other than that we need to do some compatibility testing.

Global functions to create orders/products would be very helpful in reducing code duplication. Order/Product clones of woocommerce_create_new_customer would be perfect

We agreed to not add any create functions for now, since the API will not support this in the initial release. Possibly looking into this for WooCommerce 2.2, depending on what is going to happen to WP-API after WordPress 3.8 gets released and what the roadmap of WP-API is gonna be. We'll see how this fits then.

[coenjacobs]

Getting to your other questions now, @maxrice:

/orders returns orders with any status by default, should default be processing/completed instead?

I think this really depends on how your store is handling orders and what your personal preferences are. Same goes with apps and other systems using the API later on. I say stick to any status by default.

should totals be cast to string so they're string quoted in json response?

That's probably best, right? Anything we need to think of when we do this?

When requesting a variation ID, should the response include only the variation product? or should it include the variable parent product, and the requested variation listed as the only variation?

Hmm, this is a tricky one. Having just a variation without its parent is pretty useless in most cases, but it feels more 'clean' to have just return the variation alone (maybe with a reference/id to the parent). Is there anything similar out there we can spy at, see how they are doing it? :)

Should the /coupons endpoint have a custom parameter for getting coupons by coupon code? The q parameter searches both code/description already

Will it work what @rmccue suggested here?

/coupons/:code might be appropriate here.

I like this, seems fitting and in line with all the other things we've thought of.

API keys are currently 1 per user (and API requests run under the WP permissions of that user), should we support multiple keys per user?
should API secret keys be hashed prior to storage? This would prevent accessing the plaintext key again after it's displayed + stored

I'm not that much into API's to feel comfortable answering these questions without knowing all the pros and cons. Can you give some more insight in this? Is it possible to have some of the more complex situations (I can imagine both result in some extra work) to be pushed to v2 of the API?

[maxrice]

I'll try to cover all the excellent feedback here, and update the original issue as well.

@rmccue:

You should be able to subclass and override this fairly easily, although come to think of it, some JSON stuff is mixed in with the rest, so that should be separated in WP-API.

Yep, I think the class is really well suited to a standalone base class that handles routing and other misc. tasks, and then can be sub-classed to provide JSON or XML responses (especially since the XML class will need an array to XML method).

We also need to handle this in WP-API, so anything here will help us out too. You should be able to implement OAuth completely via a custom authentication handler rather than in the server itself too (although I've haven't checked how you've done this).

Indeed, I implemented with a custom authentication handler, although it required some edits to the filter to make it useful. I'd love to see the OAuth implementation have some more eyes on it and am happy to submit a PR to the WP-API repo when it's ready for authentication stuff :)

The idea with WP-API is that WC-specific data could either be added to the top-level...

After discussing with @coenjacobs, we're going to add this as a top-level product_meta or order_meta attribute and use the filters parameter (e.g. GET /orders/123?filter['meta']=true) to return the meta along with the response.

Those should definitely be WC-prefixed unless you wholesale bundle WP-API (which is probably a Good Idea). If it makes it easier, we might be able to factor some of the classes out into separate repos. Also happy to look at refactoring code if it makes it easier for you to use now, but I don't want to move around too much just for the plugin-stage of WP-API, since we're aiming for core integration in 3.9.

I need to look closer at the get_json_url() methods since I think they need to be more than prefixed, e.g. they should return the canonical URL for the API itself, which won't be JSON-specific.

Refactor method names to snake_case if refactoring routing class

If those are in WP-API, patches would be welcome there. :)

Yeah I saw that the WP-API resource classes (WP_JSON_Posts,etc) uses camelCase for method names and I'm assuming that's because of the legacy XML-RPC API uses similar naming. Since WC has no such baggage, I think adhering to the WP Coding Standards on method names makes sense for this.

Overall having the WP-API code available has been a huge, huge help thus far and I really appreciate your feedback on the implementation.

@coenjacobs:

When requesting a variation ID, should the response include only the variation product? or should it include the variable parent product, and the requested variation listed as the only variation?

Hmm, this is a tricky one. Having just a variation without its parent is pretty useless in most cases, but it feels more 'clean' to have just return the variation alone (maybe with a reference/id to the parent). Is there anything similar out there we can spy at, see how they are doing it? :)

The closest example I can find is Shopify's API which exposes a product endpoint that returns limited information about individual variants when requesting a parent product. They have an entirely separate endpoint for variants, which might be a way to consider implementing. However, in Shopfiy every product has at least 1 variant, so it's not a true parallel to WC.

I think I lean more towards consistency in the response, since it'd be a PITA to have to account for receiving different information when you request a variation without first knowing that it's actually a variation. In this case, I like @rmccue's idea to include the full variation information and then embed the parent product in it's own attribute. That response will be the most complex one for the entire API.

API keys are currently 1 per user (and API requests run under the WP permissions of that user), should we support multiple keys per user?
should API secret keys be hashed prior to storage? This would prevent accessing the plaintext key again after it's displayed + stored

I'm not that much into API's to feel comfortable answering these questions without knowing all the pros and cons. Can you give some more insight in this? Is it possible to have some of the more complex situations (I can imagine both result in some extra work) to be pushed to v2 of the API?

I can imagine some scenarios where you'd want one API key that allowed READ permission and another that allowed WRITE permission, and both run under the security context of your WP user. The big issue here is that if you allow multiple keys per user, you then have to store them as user meta (unless you do some hacky approach like suffixing the user meta keys with 1, 2, 3, etc.), which means in order for the API to lookup a WP user given their public key, it has to find every user with that specific meta, unserialize it, and then loop through until it finds a match. This won't scale well if a site has a lot of users with API keys, but maybe we can assume most site's will only have a handful of users? @thenbrent I know you've got experience with serialized user meta ;) any input on this?

Either way, it's something we need to decide on in the v1 because it affects how we're storing the keys and it'd be nice to avoid changing our data structure for the key storage in the future if possible.

As for hashing the secret keys, it's mostly a question of convenience. Obviously once it's hashed, we can't display it to the user again, so they'd have to re-generate their secret key if they lose it. I did find that Amazon AWS (perhaps the largest implementation of API authentication over plain HTTP) is now hashing and storing secret keys, as they cannot display your secret key once you've generated and saved it.

While secret keys aren't exactly the same as passwords, they could still be pretty damaging if compromised, e.g. an attacker could delete all orders, or modifying existing ones, etc. For this reason alone it might be worth hashing.

[thenbrent]

I know you've got experience with serialized user meta ;) any input on this?

The main issue is that it makes search/retrieval a pain.

If you just need to store multiple 'woocommerce_api_consumer_key' values, then add_user_meta() can actually handle duplicate rows with the same meta_key. Just make sure $unique is false (it is by default) and a new row will be created for each 'woocommerce_api_consumer_key'.

[thenbrent]

Also @maxrice, this looks amazing.

[maxrice]

@kloon Yeah that part was done prior to some other updates, so really it should use get_woocommerce_api_url()

[jmawebtech]

Hi, I am using WooCommerce by WooThemes version 2.0.20. How do I add the REST API to an existing website?

[coenjacobs]

@jmawebtech You don't, until WooCommerce 2.1 goes out. The currently builds are not stable yet to be used on a live website. The final is going out in January 2014.

[kloon]

@maxrice Finished up the API wrapper library https://github.com/kloon/WooCommerce-REST-API-Client-Library

[thenbrent]

@kloon legend! I'll hopefully get a chance to play with that before the week's out. :)

[maxrice]

@kloon just did some initial testing, looks really nice. The OAuth stuff looks like it wasn't as bad as I imagined to work with, so that's a big plus :)

[jmawebtech]

Hi,

Has WooCommerce 2.2 and this API been released? Do you have a final release date for 2.2 and this API?

[thenbrent]

@jmawebtech the API will be in WC 2.1. Extension developers have been told to ensure their extensions are WC 2.1 compatible by 20th Jan, so I imagine the WC 2.1 release date will be a few weeks after that.

[jmawebtech]

Do you have a 2.1 beta available with the API I can use?

Sent from my Windows Phone

---

From: Brentmailto:notifications@github.com
Sent: ý1/ý14/ý2014 3:27 PM
To: woothemes/woocommercemailto:woocommerce@noreply.github.com
Cc: Joseph Andersonmailto:joe@jmawebtechnologies.com
Subject: Re: [woocommerce] REST API - Initial Implementation (#4055)

@jmawebtechhttps://github.com/jmawebtech the API will be in WC 2.1. Extension developers have been told to ensure their extensions are WC 2.1 compatible by 20th Jan, so I imagine the WC 2.1 release date will be a few weeks after that.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/4055#issuecomment-32303900.

[maxrice]

@jmawebtech https://github.com/woothemes/woocommerce/archive/v2.1.0-beta-3.zip :)

[jmawebtech]

I get a 404 error when I visit the site: http://localhost/wordpress/wc-api/v1 . I enabled the API from the WooCommerce admin. Am I looking at the right spot?

[jmawebtech]

I went to http://localhost/wordpress/index.php?wc-api-route=/wc-api/orders/count and I get this error: {"errors":[{"code":"woocommerce_api_authentication_error","message":"Invalid authentication method"}]} Is oAuth available yet?

[maxrice]

@jmawebtech do you have default permalinks enabled? If you access it over SSL you don't have to use OAuth :) see temporary documentation here

[jmawebtech]

I don't believe so. What are the default permalinks? Please send me a URL rewrite rule.

[maxrice]

@jmawebtech you'll want pretty permalinks enabled

[jmawebtech]

Alright, I have that part now. I get this error: Consumer Key is invalid. My site is on SSL. I sent Authorization in the header with USERNAME:PASSWORD Authorization: Basic xxxxx . Do I need another value? Do I need to create a special API user name and password?

Request

GET https://jmawoocommercetest.azurewebsites.net/wc-api/v1/order/count HTTP/1.1
Authorization: Basic abc
Host: jmawoocommercetest.azurewebsites.net
Connection: Keep-Alive

Response

HTTP/1.1 401 Unauthorized
Content-Length: 96
Content-Type: application/json; charset=UTF-8
Server: Microsoft-IIS/8.0
X-Powered-By: PHP/5.4.9
X-Powered-By: ASP.NET
Set-Cookie: ARRAffinity=2932530815e7e91ba378e9b97b6c873515fb298cd5a1a5cee5ac571011840e88;Path=/;Domain=jmawoocommercetest.azurewebsites.net
Set-Cookie: WAWebSiteSID=5e8352d1abd64708846cd04f3fdbfa98; Path=/; HttpOnly
Date: Fri, 17 Jan 2014 23:42:57 GMT

{"errors":[{"code":"woocommerce_api_authentication_error","message":"Consumer Key is invalid"}]}

[jmawebtech]

Hi,

I figured it out. I went to Users, scrolled to the bottom, and generated an consumer key and a secret.

[syaiful6]

Hi, maxrice. Are this available endpoint to retrieve available downloads for the given customer in API?
I think it's good idea to do that.
#4594

[emelaz]

amazing project! Almost exactly what i need. Maybe you will implement something to create products?

[maxrice]

@emelaz thanks -- product creation may be coming in 2.2, follow #4164 for progress :)

[drosanda]

can I get list of categories through api ?

[maxrice]

@drosanda product categories? nope -- if you want to see this in the next version, open an issue for it so everyone can discuss :)

[charls637]

Im having a problem, i want to display all my products lets say 426, but it will just display 4 of it..
how do we achieve it?

[andreicyr]

I am having the same problem. When I try to display all products it only displays the first 11. After that I receive the following error:

Notice: Undefined offset: 12 in /home/rmpxro96/public_html/ on line 62

[maxrice]

@andreicyr is that the only error in your PHP error log? Does it reference a specific file?

[krrishnajee]

Is it possible to Create An Order using GET method?

[claudiosanches]

@krrishnajee nop, you must use POST: http://woothemes.github.io/woocommerce-rest-api-docs/#create-an-order