3

I'm working with an ASP.net developer, under a boss who doesn't have much technical knowledge. I'm doing the front-end work, and and a database expert doing the backend.

However, recently, he said that he would be working on the API for our site- I asked why, thinking we should do the web version first, assuming the API was for mobile apps. However, he said that he would just make a single API to work for all the web and mobile apps, and I would do the front-end for that.

Is it just me, or is this a little crazy? If I'm doing front-end, it means there's going to be two back-ends, because I'm going to have to use PHP or something to curl his API to the site, which is twice the loading time as normal.

Thank for any help in advance. Also, I happen to be "the intern", so I'll have some but not very much pull with this issue.

Improve this question
6
  • 1
    Without more details on how this backend is supposed to work it is impossible to answer the question (does he mean a BLL? Rest API? Something else?)
    – Oded
    Commented Oct 12, 2011 at 14:20
  • @Oded Yeah, a REST API.
    – element119
    Commented Oct 12, 2011 at 14:42
  • 4
    You can consume an api straight from javascript (or jquery), no need for php. It's what we do with an application server which has a soap API interface. One web front-end is straight javascript/jquery calling into the soap API interface.
    – Marjan Venema
    Commented Oct 12, 2011 at 14:48
  • 10
    he said that he would just make a single API to work for all the web and mobile apps, and I would do the front-end for that -- Sounds sensible to me... The backend work only has to be done one, and all the frontends use a common API. This is a common practice.
    – Robert Harvey
    Commented Oct 12, 2011 at 14:51
  • "I'm doing the front-end work"/"I'm going to have to use PHP or something to curl his API". When you say front end do you mean client side or presentation layer on the server? If you're doing client side you don't need PHP because that's on the server. If you're doing the presentation layer you should consider ASP.NET (the MVC framework is en vogue at the moment, for very good reasons) to consume his API.
    – StuperUser
    Commented Oct 12, 2011 at 15:11

5 Answers 5

Reset to default
19

Consuming your own API is a common case. It is often called Eating your own dog food if I remember well.

Currently, I am doing the same thing for a project. I have created my Data Access Layer library, and I won't be using it directly on my web project. Instead, I will create REST APIs to reach out the data from my web site.

How I handle the authentication is another issue. What I will do is to give myself a APIKey as I will give others and go from there.

What advantages does this bring? Well, I will be handling statistics over the REST APIs and I really don't want to do the same work again. Also, by this way, my only data access concern is my API project.

Improve this answer
1
  • Thanks, had no idea. I stick to PHP most of the time, so I'm unfamiliar with ASP.net WebServices.
    – element119
    Commented Nov 7, 2011 at 21:03
1

Isn't this the correct way to abstract a site so you can have multiple front ends that display the same data, possibly in different formats? Perhaps not a full-blown API but in .NET it's fairly common to have a "web service layer" that sits on top of your DAL and Business layer, so you can write a thin front end that focuses almost entirely on display concerns only since everything it needs to work with is pulled from the web service, and this also allows you to have various front ends that all point to the same service.

Improve this answer
0

Ask him to explain how you will consume his API. Most likely, you will be developing a combination of server-side pages and Javascript to make REST calls on the website.

You might develop a page that calls the API then incorporates the response into the web page. Or dispense with writing server-side code altogether and do it with all Javascript (see http://javascriptmvc.com).

Yes, if you write code that delegates to an API via HTTP calls, it might come at the cost of some additional latency, depending on how many hops separate the code rendering the page and the server which implements the API. However, that cost has to be weighed against the code of duplication. Duplicated code is twice as expensive to maintain.

This design should not require two separate back-ends. The purpose of using a single API is to avoid duplicating the back-end code.

Improve this answer
0

Definitely represents the misunderstanding of the power of an API. Many companies build multiple back-ends for each of their internal interfaces, partner interfaces.

Identify your data and resources and deploy them as separate APIs.

Then consume them across your internal, partner and public system.

I wrote an article about this that goes into more details.

Improve this answer
0

"If I'm doing front-end, it means there's going to be two back-ends".

No, it does not. Do you mean that because there is a separation between the front end and the back end this implies that there will be either multiple front or back ends ?

Separation of presentation code (front-end) and logic is a good thing in itself. You should not mix these two concerns together. Moreover if you allow the logic to be on the back-end, then several front-ends can use the same back-end.

Also it is more common to have several front-ends to a single back-end then the case you mention: a single front-end with several back-ends.

As for his approach of creating an API to service both the standard web and mobile versions, if it is done well I see this point as beneficial.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.