Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I've exposed a few methods and, while crystal clear on how they're supposed to be used, I'm sure that with time, the memory will fade and I'll be standing there like an idiot wonder why on Earth I haven't provided any help.
When we use WCF, there's the WSDL file. But I'm not aware of any corresponding functionality for WebAPI. Usually I add a Ping so that I can type in the URL window of my browser .../Service.svc/Ping, just to see that I a date back.
What would be an intuitive and (hopefully fairly) canonical approach? I'm thinking .../Help. Is there a better way?
Just pushing out help will only produce a huge string (XML or JSON formatted), which isn't very like-a-boss'y. Anonymous types can't be well handled without serialization. pushing out object typed entity breaks the connection.
I wish to have a built-in documentation on how to use the calls. The names themselves, of course, but also what values are treated (I had a case where the .../Donkey?scope={scope} pattern could be null or all and we though it was any, which took a while to figure out.)
You might checkout Swashbuckle which would allow you to generate Swagger documentation for your ASP.NET Web API controllers.
Anonymous types can't be well handled without serialization. pushing
out object typed entity breaks the connection
Are you really exposing anything like the above mentioned in your Web API contracts. I hope you don't.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 months ago.
Improve this question
I am new to REST API, and I am designing my own REST API for my web project.
Which of the followings is the better convention?
I want to access to the article that user ID 3 wrote.
/user/3/article
/article?user_id=3
Thanks.
Which of the followings is the better convention?
They are both fine.
/article?user_id=3 may prove more convenient if you are expecting to use HTML forms as a way of finding resources.
/user/3/article may prove more convenient if you expecting to use dot segments to describe other resource identifiers in the hierarchy.
What if I want to access to the fourth article that User ID3 wrote? /user/3/article/4 is appropriate? I think this hierarchy is unnecessarily deep.
Deep hierarchies are fine. Not using deep hierarchies are also fine.
In some designs, we'll use resource identifiers for items that are not part of the same hierarchy as the collection itself
context="/user/3/article" rel="item" href="/articles/4"
context="/user/3/article" rel="item" href="/articles/9"
context="/user/3/article" rel="item" href="/articles/16"
Think "web page with links"; if you can follow a link, you don't need a formula to compute the URI yourself.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
So my friend needed to develop new API for creating item, so he developed:
POST /new/item
POST /item/new
PUT /new/item
PUT /item/new
All of them call the same underlying function and accept same parameters.
I recommended that he uses only 1 instead of 4, but he says that there is no down side and he's giving the option for anyone who wants to integrate with this API to use whatever personal variation they like.
Question: Is it really that there is no down side by doing this in the long run?
There is no downside in regards to functionality, but an API with redundant endpoints will probably be
Harder to maintain. If a change to the endpoint is needed, it may have to be made four times depending on the setup
Confusing for users of the API. While I imagine it's the intention behind this setup to catch typos in URLs and still allow the API to work, documentation on the endpoints will be bloated and harder to read
Lacking consistent naming. Ideally, there is a logic behind how endpoints are named, allowing users to infer what an endpoint does by its name and verb (GET, POST etc). Having multiple naming schemes makes it harder to understand the naming.
There is no meaningful upside to making redundant endpoints, and I would recommended to use POST /item for creating a new item.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
Hoping someone can help clear things up for me.
I've been reading a ton about the new javascript app frameworks out there, backbone.js, batman.js, ember.js etc...
And I see a lot of instances of them using the frameworks on top of Rails.
Can someone explain to me. Doesn't this require a ton of duplication in order to use them? ie. do I need to completely duplicate each model and controller? And if so, do I need to make changes to both each time?
I see a great benefit for rendering templates on the browser, but I feel like I'm missing something important when it comes to using these on top of an already well organized MVC structure.
What is the benefit and is there really as much duplication as it seems?
I've read the question here
But it doesn't seem to address the duplication.
Thanks in advance.
The benefits are described in the question you linked to. They provide structure which is hard to achieve when you're client side does more than simply displaying data and reloading parts of the view with AJAX.
Andrew Dupont gave a presentation at MIX 11 about writing maintainable JavaScript. He describes his journey from a stinking pile of JS to a more maintainable code base. It is worth watching.
The duplication depends on how much you do on the server side. If your server is only serving data, e.g. Rails controllers providing a JSON API to access the models, you have to duplicate the models on the client side.
I am using Rails only for JSON access to persist the entities of my application, except some JSON views. The whole user interaction and CRUD happens on the client with Backbone & jQuery.
So far, I had only to duplicate the models in Javascript and create some controllers for accessing and saving the models on the server.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
In the line of Questions every good Java/Java EE Developer should be able to answer?
I would like to ask what are the Questions every good Struts Developer should be able to answer?
Looking forward for some good responses.
1. What is the basic flow of a Struts handled request?
You can find a short description here and plenty of resources on the web.
(If you pretend to know Struts then there is no excuse for not knowing number 1)
Next question is "What is a Servlet?" (and I'm not kidding; if they fail number 1 they are going to fail to this also, trust me).
2. Is ActionForm part of the Model in MVC?
People think the ActionForm is part of the Model. They read the MVC description and think... Hey!... this is the Model's state, lets move this as parameters all over the Model. Now you have a tight coupling between the Model and the Struts framework.
There are plenty of examples in which the ActionForm properties are mapped 1:1 on DTO POJO objects and those used instead, but people think its a waste of code and time and just pass it along to the Model.
(Number 2 can can be excused for a junior and is later cured by experience)
3. Do you put your business logic inside the Action class? Why? Why not?
An Action is an adapter between the contents of an incoming HTTP request and the corresponding business logic that should be executed to process this request... 'nuff said
(Number 3 is also cured by experience)
Difference between filters and Interceptors ?
Action Chaining
classes used as part of struts framework.
Validation Plugin
struts Configuration.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I'm looking for a nice way to generate documentation for a REST API. It doesn't need to actually connect with the code or anything, but it'd be awesome to be able to write the documentation as text files, point the tool at it, and generate some docs from it.
Anyone out there have any ideas? I know I'm being a bit vague, but, to be honest, I'm not quite sure what I'm looking for here--mainly an easy way to manage documentation.
According to Roy:
"A REST API should spend almost all of its descriptive
effort in defining the media type(s) used for representing
resources and driving application state, or in defining
extended relation names and/or hypertext-enabled mark-up
for existing standard media types."
Self-descriptiveness is one of the benefits of REST.
While not REST, I used Sphinx to document an XML-RPC API that consisted of an API reference and a tutorial. Sphinx adds some handy directives to ReStructuredText to get pretty much what you asked for: a collection of ReStructuredText formatted-text files that Sphinx turns into HTML and PDFs, complete with an index and table of contents. Sphinx is easy to use and well-documented; I don't think it would be an exaggeration to say you could get started with it in about ten minutes.
Some RESTful systems are actually able to write their own API. Have a look at RESTx, which does just that: You write your components and then create new web services by sending parameters for those components to the server (either as JSON or via a web form). You then get a URI back for those parameters. Accessing it calls the component with the parameters and you retrieve the results.
At any rate, the components as well as the created RESTful web services get an automatically generated documentation, which is browseable and can be retrieved either in HTML or JSON format.