nzsmartie / oicnet Goto Github PK

Often OicResponseUtility.CreateMessage(OicResponseCode, string) is used to create a response to an request. But the responses are not consistent and don't provide any formatting options (yet).

Would be a good idea to create a string resource (not possible in .Net Standard parameters.

Based on #5

Typical MVC framework with default views for serialising into JSON, CBOR or XML (see #2)

OIC Core spec only requires application/cbor media type for messages. but also allows for application/json and application/xml

As I've forked Newtonsoft.Json.Bson to create Newtonsoft.Json.Cbor which adds CBOR (RFC 7049) support to the popular JSON.Net library, it covers the applicaiton/cbor requirement and as a bonus natively supports application/json but is a miss with application/xml

Luckily, .Net works well with XML, so it shouldnt' be too hard to work in serialisation, but for now, it's not a huge requirement.

If you need this support. Thumbs up this issue and i'll look into it

Until .Net Standard 2.0 is released, Embedded Resources isn't available. So all serialsied classes must me manually maintained to cconform to OIC's specification.

In the future, the json schemas provided in OICNet/IoTDataModels will be the source of truth and used to generate JSON/CBOR messages

This is to keep track of what's implemented and what should need focus on next.

This is as of yet unplanned but will be looked at after the the library becomes stable.

This task is bottlenecked until I can get a virtual environment set up (hopefully through #5 and #6) in Windows for easy testing

Operations that need to be supported

• Create (POST/PUT)
  • POST: An existing URI to a resource responsible for the creation
  • PUT: A new URI for the resource
• Retreive (GET)
• Update (POST)
• Delete (DELETE)
• Notify (OBSERVE)

This class already supports automatic deserialisation to OIC resources based on the resource's rt property (related #1)

ASP.Net is an ideal framework for highly configurable application stacks. And it provides a familiar API to existing .Net developers for quickly getting started.

As ASP.Net has a strong focus around HTTP, it didn't seem work while to fork the entire repository when a limited subset of classes were needed. A clone has made that meets minimum requirements of logging, dependency injection, hosting the application, providing a startup interface and so forth.

It makes sense to use existing OIC schemas. using them in C# would require some runtime processing of the schemas, or compile-time generation of class objects.

• Using provided base schemas, support reading any oic.r.* schema
• Create a C# class file that reflects the input schema
• Provide metadata for consumption through the API such as (read-only, valid ranges, etc)
• Write tests to ensure future changes do not break builds

Much like StaticFile for ASP.Net, add an application layer that will match a request with a resource and return it's contents.

It must

• Serve resources
• Provide a method of adding resources from the application to be served.
• Optionally configure resources to be directly updated