Identifying different types of class feed posts

[DanielThePear]

@ctrezevant Hey! I don't know if the Issues channel is the right place to ask this question, but I wasn't able to find a more appropriate location. When developing PyEdsby, did you ever develop a method of differentiating between the types of posts in a class feed? I.e. normal text posts, replies to posts, assignment posts, and probably several others that I haven't discovered

I've found that the criteria for a like/unlike POST request differs between the types of class feed posts.

[chtzvt]

Hey @DanielThePear!

You're more than welcome to use the issues channel for this discussion- we have a questions tag, after all :)

During the initial development of PyEdsby, my work was essentially limited to replicating the HTTP requests made by the application in Python. While this approach is somewhat brittle, it enabled a rapid pace of development that suited my own needs.

Later on, I had the pleasure of being able to speak to the CoreFour team directly, who were actually kind enough to clarify a few things for me:

• First, that Edsby is built on a graph database, which is somewhat helpful in better understanding how data is represented in requests/responses. That's why you see NID (node IDs) and RID (relationship IDs) everywhere.

• Secondly, what XDS is. You may have noticed xds appearing in many URLs. You may have noticed X-Powered-By: CoreFour.XDS among the Edsby response headers. The term seems to be scattered around quite a bit.

XDS is a proprietary templating and interchange format developed by CoreFour. I have a little bit of descriptive matter about it in the wiki:

Edsby's client-facing backend is powered by a system called XDS, which is proprietary to CoreFour. XDS includes the data requested in the API call, as well as a wealth of other metadata. XDS combines a number of interrelated pieces of data into a single response document, including templating and schemas, permissions management, the web application's own state, and more.

The most robust approach would of course be to parse the XDS payloads returned by the server in order to interact with the application. However, writing a parser for an undocumented proprietary interchange format is too much work (in my opinion), especially given that the API seems fairly stable and fixes are quick if something were to change.