NTA Contribution - A REST API to query NTA data

[amila17]

Introduction

This contribution aims on implementing a REST API for the NTA module to expose the data processed. In addition, a sleek new UI would be developed to represent the data queried by the API. This would eventually replace the current JSF implementation in the NTA module.

The REST API would be implemented using the RESTEasy framework developed by Jboss: RESTEasy - JBoss Community and the new UI will be implemented using the JavaScript MVC framework named AngularJs: http://angularjs.org/

An initial discussion with the NTA team (Paul Robinson and Tom Jenkinson) has been carried out and it was proposed that a link to the REST API documentation to be placed here for community feedback: http://docs.ntarestapi.apiary.io/ (The feedback could be written as comments in the apiary document).

The DB design for NTA is attached below. This will give an idea of how the entities are related and how the API will query these entities.

Looking forward to any feedback and suggestions.

Thank You,

Regards,

P G Amila Prabandhika

[paul.robinson]

Amila,

Thanks again for agreeing to do this work. it really is much appreciated!

It looks like Apiary has a comment feature, it wasn't clear to me if that was a place to discuss the proposed API or a way of documenting it. I added one comment anyway, let me know if that was the wrong thing to do.

I've also attached a copy of the DB schema, as that should help review the REST API.

Unfortunatly, you have caught me at a busy time, with Red Hat Summit and DevNation coming up next week. however, I do hope to spend some time reviewing this API whilst travelling tomorrow.

Paul.

[paul.robinson]

Amila,

Maybe you could attach the diagram, Amos produced, to the introduction at the start of this thread. That should make it easier for people to review.

Thanks.

[tomjenkinson]

Also, when we met face-to-face it appeared as though the intention was to replicate the features provided by the current implementation of NTA. Are we agreed that this is the correct path or should we be more ambitious and look to a next-gen version with the features we would like to have?

[amila17]

Hi Paul,

I have attached the DB image as requested. Apiary is the right place to put the comments as its easier to cross check and clarify. I have updated the post to specify that.

However, I did not see the comment you have put in.

I am glad to contribute to this project as its very interesting.

Thanks.

[paul.robinson]

Tom,

I think we just aim for the current feature-set. We can iteratively enhance the UI afterwards.

Paul.

[tomjenkinson]

Amila Palahepitiya Gamage wrote:

However, I did not see the comment you have put in.

Same here, I can't see the comment either, do I have to go some different "view"?

[zhfeng]

Tom,

I can see your comment.

[paul.robinson]

Amila,

I've commented on the API. Thanks again, it looks good and with my suggested changes I think it would be fine.

However, it would probably be better to simplify it for this version to just offering '/nta/rest/api/v1/transaction' and '/nta/rest/api/v1/transaction/{id}' . The list all transactions API (with pagination, an option for brief results, and a query-by-outcome option) would nicely map onto what is required to make the NTA console's homepage work. The  '/nta/rest/api/v1/transaction/{id}'  API would then be used on the Transaction detail page to return the details of a particular transaction. If you embed the resource manager and participant record data into the transaction data structure, then you can do this with a single request, thus not having to make multiple calls for each reference.

Paul.

[paul.robinson]

Amila,

Apologies for the delay in reviewing this. It's been a busy time with the conference and then I took some Holiday when I returned. I should be a lot more responsive now.

Paul.

[amila17]

Hi Paul,

Thank you for reviewing the API docs and hope u had a great conference.

I have gone through the comments and the feedback. I will do the necessary changes required and in the mean time I have replied to some of the comments. If I come across any doubts will let you know.

I also met with Alex recently and discussed about some ideas that I proposed to him on a Generic DAO layer implementation as the current DAO object handles DB operations to all entities.

Thank You,

Amila

[mmusgrov]

The is no documentation of the media types for response bodies.

Also, Paul talked about embedding the resource manager and participant record data into the transaction data structure. This in not the RESTful way of doing things, you should instead embed links to those resources.

[paul.robinson]

Mike,

Ah yes, I agree. I was thinking about limiting requests, but I don't think that is important. It would be more important to follow a cleaner pattern. Does the API as it stands follow good RESTful practices?

Paul.

[paul.robinson]

Amila,

Feel free to refactor the DAO layer if you need to decouple it from the DB logic.

Paul.

[amila17]

Paul,

Sorry for the late reply, was having some trouble getting RESTEasy 3.0.6  to integrate with CDI. There is a bug which is reported by several users, as a result had to use a lower version of RESTEasy to kickoff the work on the project.

Regarding the transaction data that is returned, I was going to return the data for participant record and resource manager as values. However, this could mean that the exchange of payload is big. Therefore, as Mike has suggested above, I will return the REST links for entities within another. 

Coming onto the DAO layer, I would like to have a look into it, but prior to that I will complete the REST API first.

Thank You.