REST API Endpoints

[Charles]

The REST API is a great feature that allows you to easily interface with the functions of IPS Community Suite programmatically from an external system.

We are adding more endpoints in 4.2 to the REST API so please let us know any functions you would like to see.

If none of this make sense to you then feel free to ignore

[Tom Christian]

- User authentication (login/register/reset password)

- List categories

- List forums

- PM's (CRUD)

On the subject, better marketplace integration e.g. get account credit. I wrote a bot that scrapes this for my own use but would be nicer to have an endpoint.

 

[HeadStand]

- node-level endpoints, like @Tom Christian suggested. List nodes. List items within a node (instead of the current item endpoints that rely on node filtering parameters; those are designed more like search methods).

- user authentication/registration, but along with that, the API should honor permissions. Make use of the framework classes and methods instead of just running new database queries. So much wasted potential here.

- I would suggest two structures of output for certain classes, one with "header" data and one with full data. For example, the current \IPS\Member::apiOutput sends back a TON of information. When getting topic data, for example, we don't need all that. 

I'm sure there's more, but I'm on my phone now and I can't think of it. 

[Coment]

As I posted a year ago, I'd like to see more filtering overall:

-When getting /members, parameters for primary group, joined date, customFields maybe...

-When getting posts from a topic, parameters for user/s, IDs...

It's crazy how it returns so much information, but you can't preemptively use it to suit your needs.

[Vatutin]

Would be great if you implemented limiting system to api requests per key per standpoint. This way I could integrate it with commerce and sell my api (I have an application with currency exchange rates).

[GTX3]

What I personally would like to see:

• Get latest IP of a member
• Get post's likes
• I don't know if that exists already, but perhaps a parameter that limits how many posts to fetch to topics controller (for example, I would need to fetch only the first post)
• Fetch activity (of a member or all activity)
• Fetch profile's cover photo
• Leaderboard stuff

You can get few ideas from here https://invisionpower.com/files/file/8061-ipbwi-api-v4-extended-edition/

And it's nice to see IPS taking an interest to REST API!

 

[HeadStand]

3 hours ago, Vatutin said:

Would be great if you implemented limiting system to api requests per key per standpoint. This way I could integrate it with commerce and sell my api (I have an application with currency exchange rates).

I think that's already possible.

[Vatutin]

12 hours ago, HeadStand said:

I think that's already possible.

I'm sorry, I meant limiting requests (say, 6 requests per hour).

[Real Hal9000]

On 3/19/2017 at 6:31 PM, Tom Christian said:

- User authentication (login/register/reset password)

- List categories

- List forums

- PM's (CRUD)

On the subject, better marketplace integration e.g. get account credit. I wrote a bot that scrapes this for my own use but would be nicer to have an endpoint.

 

Can't emphasize enough the need for all these api's Christian mentioned :-) We are waiting for them for a long time.

And let me add Like too (post/get)

 

 

[IPBWI.com Matthias Reuter]

On 19.3.2017 at 5:31 PM, Tom Christian said:

- User authentication (login/register/reset password)

- List categories

- List forums

 

user authentication works with IPS connect perfectly, so I see no need to integrate that into REST API

list categories and forums is available in my marketplace addon, even though I understand you prefer not to pay for a third party app for these endpoints and want them built into IPS REST API. But many customers would prefer new endpoints never available before instead of replacing features which are already available on market

E.g. I would prefer endpoints for permissions, e.g. "can_read", "can_reply" by user_id - including permission group creation/deletion/edit at all. As this is some kind of complex, I would prefer IPS would take care for these endpoints. Many users out there want to get the great IPS permission system integrated into custom apps.

[HeadStand]

16 minutes ago, IPBWI.com Matthias Reuter said:

user authentication works with IPS connect perfectly, so I see no need to integrate that into REST API

For something like a mobile app, IPS Connect is not necessarily the appropriate solution.

16 minutes ago, IPBWI.com Matthias Reuter said:

But many customers would prefer new endpoints never available before instead of replacing features which are already available on market

Most customers would prefer to have a single API that handles all of their needs, instead of having to install additional plugins just to get endpoints that really should be included.

16 minutes ago, IPBWI.com Matthias Reuter said:

E.g. I would prefer endpoints for permissions, e.g. "can_read", "can_reply" by user_id - including permission group creation/deletion/edit at all. As this is some kind of complex, I would prefer IPS would take care for these endpoints. Many users out there want to get the great IPS permission system integrated into custom apps.

I think it makes more sense to have the permissions included in the objects returned instead of a separate endpoint. If I get a list of topics, it should include canRead, canEdit, canDelete, etc, in there. It would be horrible to have to make a separate API call for each individual permission and object. Imagine checking permissions on a list of topics! If permissions were endpoints, you would potentially be making 6-7 calls PER TOPIC in the list. It's much easier to just include the permissions in the original call.

[IPBWI.com Matthias Reuter]

8 minutes ago, HeadStand said:

For something like a mobile app, IPS Connect is not necessarily the appropriate solution.

What's the lack here with IPS connect you feel confronted with? What should be changed/add to fit your needs with mobile apps?

8 minutes ago, HeadStand said:

Most customers would prefer to have a single API that handles all of their needs, instead of having to install additional plugins just to get endpoints that really should be included.

Not sure, but I think this can be said to every single feature request IPS has got in the last years: "This should be included, this is obligatory, why we need third party apps for a core feature like this." Don't forget IPS needs to maintenance new features in future - third party apps help IPS consider some tasks as "done". No need to reinvent the wheel, when there are enough other undone feature requests out there.

8 minutes ago, HeadStand said:

I think it makes more sense to have the permissions included in the objects returned instead of a separate endpoint. If I get a list of topics, it should include canRead, canEdit, canDelete, etc, in there. It would be horrible to have to make a separate API call for each individual permission and object. Imagine checking permissions on a list of topics! If permissions were endpoints, you would potentially be making 6-7 calls PER TOPIC in the list. It's much easier to just include the permissions in the original call.

Think your suggestion is correct, but I would prefer both ways, yours and mine, to allow the fastest / most convenient way in all situations.

[HeadStand]

4 minutes ago, IPBWI.com Matthias Reuter said:

What's the lack here with IPS connect you feel confronted with? What should be changed/add to fit your needs with mobile apps?

How does using IPS Connect help me maintain a session within the API? The point is not to just authenticate. The point is to make the entire API return data based on the current user. If I authenticate with IPS Connect, the API knows nothing about it, and therefore, it still won't return data based on who I am.

4 minutes ago, IPBWI.com Matthias Reuter said:

Not sure, but I think this can be said to every single feature request IPS has got in the last years: "This should be included, this is obligatory, why we need third party apps for a core feature like this."

That is 100% correct, and that's the general feeling that I get reading feedback on this site. But we're not talking about "just 3rd party apps". We're talking about adding in endpoints that deal with core data. Returning a list of forums should not require a plugin.

4 minutes ago, IPBWI.com Matthias Reuter said:

Think your suggestion is correct, but I would prefer both ways, yours and mine, to allow the fastest / most convenient way in all situations.

I cannot think how your suggestion would be faster in any situation, but you do you. 

[IPBWI.com Matthias Reuter]

3 minutes ago, HeadStand said:

How does using IPS Connect help me maintain a session within the API? The point is not to just authenticate. The point is to make the entire API return data based on the current user. If I authenticate with IPS Connect, the API knows nothing about it, and therefore, it still won't return data based on who I am.

I see no problem with authentication with IPS connect first - which gives me a valid user ID - and using that to retrieve data for the given user. Session management is up to your app and should not be part of REST API or IPS connect at all.

3 minutes ago, HeadStand said:

That is 100% correct, and that's the general feeling that I get reading feedback on this site. But we're not talking about "just 3rd party apps". We're talking about adding in endpoints that deal with core data. Returning a list of forums should not require a plugin.

Yeah, I agree that forum endpoints should have been part of the core. Since it wasn't available at all until I've provided that through my app, it's more a question about marketplace- and product strategies of IPS: If they would integrate features already done by third part app, it's a big demotivation for third party developers, as this is a signal that effort for developing such a feature can become obsolete within a year. Unfortunately, IPS is not giving any long-term feature forcasts. E.g. I've asked IPS whether there are plans to integrate an IPS slave manager into IP.board. Answer: it is planned, but no ETA. I've asked whether they won't develop that when I provide such a solution right now. Answer: No, they will release their feature anyway, but still no ETA. So that's why some urgently needed features are not available today, as I will not work for trashcan.

3 minutes ago, HeadStand said:

I cannot think how your suggestion would be faster in any situation, but you do you. 

e.g. if a form for a new post in a topic has been sent from your app, you don't need the full topic data to handle request, you just need to know whether the user can post and create it then.

[HeadStand]

3 minutes ago, IPBWI.com Matthias Reuter said:

I see no problem with authentication with IPS connect first - which gives me a valid user ID - and using that to retrieve data for the given user. Session management is up to your app and should not be part of REST API or IPS connect at all.

I shouldn't have said session management, bad choice of words. What I meant was how will the API know who you are? Passing in the user ID is one solution, as long as you're passing the user ID to the API and letting the API give you back the appropriate data.

4 minutes ago, IPBWI.com Matthias Reuter said:

Since it wasn't available at all until I've provided that through my app, it's more a question about marketplace- and product strategies of IPS: If they would integrate features already done by third part app, it's a big demotivation for third party developers, as this is a signal that effort for developing such a feature can become obsolete within a year.

Cute. I developed my Social Stream app after repeatedly asking IPS if something similar was planned. I was told no. Released my app. Activity Streams came about 2 months later. Which is fine, because there's still enough of a demand for the Social Stream. Third-party development always has that risk attached, it's part of the job. You don't like it, don't do this job.

And while we're on the topic, I happen to have already built a fully functioning REST API that includes registration, authentication, and is permission-based. I haven't seen a single suggestion in this topic that is not already handled by my API. Am I saying that people should buy it instead of having IPS change theirs? No. The ONLY reason I built mine in the first place is because I felt that the existing API was severely lacking. If IPS is asking for suggestions on how to improve their functionality, I am more than happy to pass on the things I've learned from my experiences on this particular topic.

8 minutes ago, IPBWI.com Matthias Reuter said:

e.g. if a form for a new post in a topic has been sent from your app, you don't need the full topic data to handle request, you just need to know whether the user can post and create it then.

If you don't have permission to reply to a topic, you shouldn't have the form available in the app in the first place.  

[Lewis P]

There only thing standing out to me as being useful for what I'm working with at the moment that haven't already been mentioned is Search - with all the existing on-interface options available as request parameters/body one way or another.

[IPBWI.com Matthias Reuter]

Just now, HeadStand said:

I shouldn't have said session management, bad choice of words. What I meant was how will the API know who you are? Passing in the user ID is one solution, as long as you're passing the user ID to the API and letting the API give you back the appropriate data.

The REST API just provides information as needed. Checks to identify a user need to be done with IPS connected or within your app, e.g. by user-id, by email, loginname, displayname, cookies (set by your app) etc.

Just now, HeadStand said:

Cute. I developed my Social Stream app after repeatedly asking IPS if something similar was planned. I was told no. Released my app. Activity Streams came about 2 months later. Which is fine, because there's still enough of a demand for the Social Stream. Third-party development always has that risk attached, it's part of the job. You don't like it, don't do this job.

And while we're on the topic, I happen to have already built a fully functioning REST API that includes registration, authentication, and is permission-based. I haven't seen a single suggestion in this topic that is not already handled by my API. Am I saying that people should buy it instead of having IPS change theirs? No. The ONLY reason I built mine in the first place is because I felt that the existing API was severely lacking. If IPS is asking for suggestions on how to improve their functionality, I am more than happy to pass on the things I've learned from my experiences on this particular topic.

My condolences If IPS is going to release forum management endpoints into core, I'll not start to complain everyday. But everything has consequences, as we all do business and try to get our daily meal on the table. Currently, IPS is taking care more than before for their third party app developers and I will not stop working on apps when some of them are going to be obsolote or banned from IPS marketplace (actually happened). Again, everything has consequences, e.g. in prices per license, amount of new high quality apps, etc.

Of course we all can build new features just for fun, as technology study for our own websites or for pocket money. That works in some cases, in some not. There are cases where professional third party apps with high quality customer service have a need on market. Professional support requires a regular income. If all successful apps get replaced by IPS core sooner or later, your professioal third party developers with reliable service and support will bleed out.

1 minute ago, HeadStand said:

If you don't have permission to reply to a topic, you shouldn't have the form available in the app in the first place.  

correct, but for security purposes, permissions should also be checked after form submission. You know...I can build such a form on a site on the fly with developer console or write scripts firing POST requests. Showing/Hiding forms based on permissions is a usability thing, checking for permissions after submission is a security thing

[HeadStand]

2 minutes ago, IPBWI.com Matthias Reuter said:

If IPS is going to release forum management endpoints into core, I'll not start to complain everyday.

I'm not complaining. I was just saying that it happens to all of us.

2 minutes ago, IPBWI.com Matthias Reuter said:

If all successful apps get replaced by IPS core sooner or later, your professioal third party developers with reliable service and support will bleed out.

That depends on the business model. I personally view the marketplace as advertising, nothing more. It brings me very minimal revenue (a year's revenue MIGHT bring me 2 months of the mortgage. Might). The majority of my income comes from private clients, who want continual custom development for their sites. That's not going to be affected by any changes IPS makes. If there's one thing I've learned here, it's that no two communities are alike, and they never want exactly the same features. I have a Courses app that I built for one of my clients - and I actually have 4 different implementations of it, for 4 different communities. So no, I don't think that we'll all disappear any time in the near future, quite the opposite. A strong core framework will bring in MORE developers.

7 minutes ago, IPBWI.com Matthias Reuter said:

correct, but for security purposes, permissions should also be checked after form submission. You know...I can build such a form on a site on the fly with developer console or write scripts firing POST requests. Showing/Hiding forms based on permissions is a usability thing, checking for permissions after submission is a security thing

Yes, and the API should be checking it and throwing back an error if you don't have permission to be doing that. There's security on both ends - it's not sufficient to have your client do the permission check, because what if you have a careless developer building the client? If we're talking security, then the API itself needs to be secure. Relying on 3rd party developers to make the right choices is not a good approach.

[IPBWI.com Matthias Reuter]

1 minute ago, HeadStand said:

I'm not complaining. I was just saying that it happens to all of us.

was never my intention to postulate this. Just wanted to explain that bad things happen to us app developers, but it has consequences in motivation and business decisions (positive and negative).

1 minute ago, HeadStand said:

That depends on the business model. I personally view the marketplace as advertising, nothing more. It brings me very minimal revenue (a year's revenue MIGHT bring me 2 months of the mortgage. Might). The majority of my income comes from private clients, who want continual custom development for their sites. That's not going to be affected by any changes IPS makes. If there's one thing I've learned here, it's that no two communities are alike, and they never want exactly the same features. I have a Courses app that I built for one of my clients - and I actually have 4 different implementations of it, for 4 different communities. So no, I don't think that we'll all disappear any time in the near future, quite the opposite. A strong core framework will bring in MORE developers.

Generally, if something is easy to develop, an app developer need to face that an app is going to be obsolete sooner or later. Of course, customization for customers helps here a lot, but I prefer building apps for everyone - based on customized features. You are right, there are features out there with a market existing with just one client, as it's too specific to be usable for other people out there. If you can reduce your app prices, as custom work gives you enough money back - cool! I appreciate the marketing effect of my apps, too, but a vibrant marketplace should be able to honor the effort of app developers on a monetary way through license sold, too.I would love to see your opportunities and great apps if you could live from the license fees. Same for myself.

1 minute ago, HeadStand said:

Yes, and the API should be checking it and throwing back an error if you don't have permission to be doing that. There's security on both ends - it's not sufficient to have your client do the permission check, because what if you have a careless developer building the client? If we're talking security, then the API itself needs to be secure. Relying on 3rd party developers to make the right choices is not a good approach.

In some cases, you want to prepare posts or fire actions before submission - Great if you could check for permissions first before starting the engine.

[Aiwa]

Can the side conversion go elsewhere? REST API endpoints is the topic at hand, not if your marketplace apps become obsolete by IPS baking into an app /  core. 

[HeadStand]

1 hour ago, Aiwa said:

Can the side conversion go elsewhere? REST API endpoints is the topic at hand, not if your marketplace apps become obsolete by IPS baking into an app /  core. 

Fine. I stand by my position that the REST API needs authentication, registration, and permissions. And forum lists.  You do realize that that was the topic of conversation, and not the marketplace....